Helo Werner,
I did not mean to be impatient. I did not know those problems. May be you
can tell me about those problems or a comfortable environment for you. So,
I could prepare the example for that environment (another databse such as
MySQL, or another J2EE container, etc).
I will be open to any suggestion you could have,
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:45
Por favor, responda
a user
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]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
