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