Here is what I've been fighting with and has been causing me great frustration: java.sql.SQLException: ORA-01555: snapshot too old: rollback segment number 1 with name "PURGERBS1" too small The segment is set right after obtaining the connection using oracle-specific SQL
What this means is that the rollback segment is too small for the queries I am running on the database (we're copying blobs...). The code is using straight SQL on a connection to an oracle DB obtained from the weblogic EJB container.
We can live with only part of the data being actually treated because we'll get an error and it's stil better than nothing (we are cloning data basically)
Ok... easy then I'll just mark the method where all this is done as NotSupported in the deployment file... still won't work. Oh... but that's because Oracle only support Read Commited and Serializable ! Duh... thanks for making me believe I could make a bean method work outside of transactions !
Ok... so I'll try to set the connection isolation... of course I can't because I can't set it to None and because the container will just ignore it anyway I think
Next idea is to make the bean method handle the transaction and commit every so many queries, but I can't get a UserTransaction object unless the whole bean is made BMT which I do not want to do.
Humm.. I'm sure this is bad but perhaps I can just call commit() on the connection object I get from the container. Surprise surprise... it doesn't shout or yell but it crashes the same way on a different rollback segment... X-files as far as I'm concerned
I've run out of ideas so I will just un-optimize the code and get a new connection and statement for every add and remove I make.
Or maybe I'm just suffering from the sizzling heat in Paris and can't think straight ?
One of the things I miss most from working with Clearcase at my previous company is branching information (I currently use CVS)
We use CVS with a "product development" philosophy : the HEAD branch has all the main development. At some point, we create a maintenance branch which has the first release for that version. For exemple we have an Xxx_5_2 branch which has all the maintenance version for the software : 5.2.0, 5.2.1, etc... This means that we can have one person fixing a bug, put it into production while at the same time developping new features.
When such a fix occures, we then merge back into HEAD... typical config management...
However, I find it fairly difficult to track what branches exist for a given file or, worst even, what merges occured. Imagine, one of those bug fixes is not merged... that would be very bad.
Up until now, we've been getting around that by being extra careful about how we run things around bug fixes and by commenting commits subsequent to a merge explicitly. But it's still not too great.
I happened to stumble across viewCVS and the latest cvsgraph and I finally have what I've been missing :) viewCVS is just a cvsweb clone into which you can plug cvsgraph.
CVSgraph displays a graph of all reversion, branches and tags very cleanly, it has lots of nice features like branch folding, only showing tagged revisions, etc...
The one thing that really got me going is automatic branching detection based on tag names. Suppose that when you release version 4.2.1 for example (remember it has to be on the maintenance branch for us) you tag it somehting like release_MYSOFTWARE_4_2_1. It's then easy to check it out cleanly.
Then you switch to your HEAD branch and merge it. You commit those changes and tag that branch merged__MYSOFTWARE_4_2_1. cvsGraph will then draw a little line between those two tag boxes to let you know that a merge occured.
The matching uses regular expressions so I suppose you can make up even more intricated schemes but I haven't fooled with that yet. I'd like to find a way to tag temporary branches and merges differently but that will be another post...
Just noticed lately that the development team is talking more about issues during the day : technical problems, architectural problems, what things mean, etc... Way more than just 3 months ago...
I mostly trace it to just having the people get used to talking to each other through regular meetings (Technical weekly and iteration retrospective every month more or less). Yeah... up until soon, meetings weren't scheduled... ever ! So they never took place and were never deemed necessary.
And incidentely, we're converging towards a commonly acceptable solution to issues during the weekly technical meetings much faster than ever..
So meetings are not all a waste of time :) I feel we wouldn't be where we are without them because habits needed to be changed.
Anyone ever notice this ?
While driving home tonight, I saw some guy on a segway on a Paris sidewalk ! Wow I didn't expect that. He didn't even seem to be garnering that much attention.
I really watched closely as he balanced his body to move around people and slow down. Also, watched his little jump to get over the curb... It would be fun to try it out some time.
I wonder where he stores that $4950 device during the day or at work !