Raul, I really acknowledge your desire to see this fixed, but I for example have no access to Oracle. I'll try my best to setup a similar environment, and will report any progress through the Jira issue.
Werner > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 18. Jänner 2006 14:32 > To: [email protected] > Subject: RE: [castor-user] Problem with Castor in a J2EE Environment > > > All right. > > But the only requirements you need to run the example are: An > oracle 9i database instance (you must replace "SID" in > "oracle-ds.xml" with the name of it) and the JBoss container. > There are as well 2 scripts in the "database" directory to > create the user "rooms" and the tables and data needed. > > The "build.xml" given will compile, build the CastorTest.ear > and copy it to the "default" server of JBoss, as well as all > the required libraries and files. > > The when you run JBoss, it will be automatically deployed. > > Raúl. > > CEIN, S.A. > > Raúl Sanz de Acedo Pérez > > Técnico Sénior - Dpto. Innovación > Empresarial > > [EMAIL PROTECTED] > > Polígono Mocholí - Plaza Cein, > 31110 Noáin > > > > > > > > > > "Werner Guttmann" > > > <[EMAIL PROTECTED] Para: > <[email protected]> > > in.com> cc: > > > Asunto: RE: > [castor-user] Problem with Castor in a J2EE Environment > > 18/01/2006 14:22 > > > Por favor, responda > > > a user > > > > > > > > > > > > > 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] > ------------------------------------------------- > > > > > > > > ------------------------------------------------- > 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] -------------------------------------------------
