Raul, I have seen the issue as raised by you, but this is not really easy to 'replay', as you in the end require me to deply jBoss, etc. Let me think a bit of whether there's anotehr (easier) way of supplying us with a test case.
Werner > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 18. Jänner 2006 13:54 > To: [email protected] > Subject: Re: [castor-user] Problem with Castor in a J2EE Environment > > > Helo again, > > Sorry for the delay. I have been trying to make a simple > example showing our problem. > > I have open an issue in jira as you suggest us. It is called > "Problem with Castor in a J2EE Environment" and the key is > "CASTOR-1301". > > Thank you very much, > > Raúl. > > > > > > > Ralf Joachim > > > <[EMAIL PROTECTED] Para: > [email protected] > > n-world.de> cc: > > > Asunto: Re: > [castor-user] Problem with Castor in a J2EE Environment > > 05/01/2006 16:36 > > > Por favor, responda > > > a user > > > > > > > > > > > > > Hi Raúl, > > In local mode the cache is updated and the locks are released > at the end of the commit() method. In global mode > (transaction managed by J2EE > container) the container have to call beforeCompletion() and > afterCompletion() methods of > javax.transaction.Synchronization interface when the global > transaction is commited or rolled back. These interface is > implemented in org.exolab.castor.jdo.engine.DatabaseImpl. The > implementation of the interface methods normally should > update castor's cache and release the locks. > > According to what I have found so far the locks should be > released if the global transaction is committed between your > 2 operations. If this is not the case as you described in > your mail, that seams to be a bug that we have not recognized so far. > > I suggest you to create a new issue in jira and, as this may > be quite difficult to find, attach a test case that allows us > to reproduce the problem ourself. > > Regards > Ralf > Castor JDO, committer > > > [EMAIL PROTECTED] schrieb: > > Helo, > > > > We have been using castor 0.9.5 in oc4j (an oracle > container for j2ee) > > against an oracle database for a long time. We needed to > log the SQL > > statements that castor produce so we decided to move to the last > > version > of > > castor. We have tested 0.9.9.1 and 1.0M1 . We are having > some problems > with > > the locks of castor over the models in an active J2EE > transaction. We > > are at a stage where we are thinking of moving away from castor. > > > > Any solutions for our problem will be greatly appreciated. Let me > introduce > > the problem: > > > > Transactions are managed by the container, so castor works within a > > transaction. Therefore, castor does not create or commit > anything at > > all, the container do so. > > > > Imagine there is an active j2ee transaction started by the > container > > that enfolds several operations. One of them is the loading of a > > object (for example; with identity 7) from the database > with castor. All works fine: > > > > load(){ > > Database db = jdo.getDatabase(); > > Object foo = db.load(foo.class, new Integer(7), > Database.Shared); > > db.close(); > > } > > > > Then, some other operations take place. Finally the object > previously > > loaded must be deleted. So, we do what follows: > > > > delete(){ > > Database db = jdo.getDatabase(); > > Object foo = db.load(foo.class, new Integer(7), > Database.Shared); > > db.remove(foo); > > db.close(); > > } > > > > The application gets blocked in the remove operation > because the first > > database still holds a lock over the object that has not > been released > with > > the close operation. Why? > > > > Only the commit() and rollback() operations release that lock but we > cannot > > make such operations because is the container the one that do so. > > > > The only way to succeed is not to close the database and to keep in > > order to make the remove operation with that same first database. > > However, > there > > are a lot of other operations in the middle. It is quite > difficult to > > control that no one else loads the same object with another > database > > in > the > > same transaction because they will block each other. Besides, you > > suggest to perform small operations with a database and > always close it. > > > > Any suggestion? Is this a bug? Should not the close > operation release > > the lock over the object in a j2ee environment? How must we > deal with this? > > > > Thanks in advance, > > > > Raúl. > > > > > > > > ------------------------------------------------- > > If you wish to unsubscribe from this list, please send an empty > > message to the following address: > > > > [EMAIL PROTECTED] > > ------------------------------------------------- > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please send an > empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > > > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please send an > empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
