Hi, Create a new Jira issue at http://jira.codehaus.org/browse/CASTOR, and attach your test case.
Regards Werner Guttmann Castor JDO, committer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 17. Jänner 2006 14:40 > To: [email protected] > Subject: [castor-user] Problem with Castor in a J2EE Environment > > Helo, > > Forgive the delay. I am really sorry I have not answered yet. > But I have been trying to make a simple example that > demonstrates the problem explained a week ago. > > However I do not know how can I attach the example. > > Thanks in advance, > > Raúl. > > P.D.: We use Shared locking. > > -------------------------- > > I'd be very interested in knowing what castor locking you're > using on the object that's having the problem, as well; > > F.ex., DbLocked would behave differently, under these > circumstances, then shared, I'm guessing. > > On 5 Jan 2006, at 15:36, Ralf Joachim wrote: > > > 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 > > > > > > rsanz <at> cein.es 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: > >> > >> user-unsubscribe <at> castor.codehaus.org > >> ------------------------------------------------- > >> > > > > ------------------------------------------------- > > If you wish to unsubscribe from this list, please send an empty > > message to the following address: > > > > user-unsubscribe <at> castor.codehaus.org > > ------------------------------------------------- > > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please send an > empty message to the following address: > > user-unsubscribe <at> castor.codehaus.org > ------------------------------------------------- > > > > ------------------------------------------------- > 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] -------------------------------------------------
