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