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]
-------------------------------------------------
