Helo,
Forgive the delay. I am really sorry I have not answered yet. But I have
been trying to make a simple example that demonstrates the problem
explained a week ago.
However I do not know how can I attach the example.
Thanks in advance,
Raúl.
P.D.: We use Shared locking.
--------------------------
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
>
>
> rsanz <at> cein.es 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:
>>
>> user-unsubscribe <at> castor.codehaus.org
>> -------------------------------------------------
>>
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> user-unsubscribe <at> castor.codehaus.org
> -------------------------------------------------
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
user-unsubscribe <at> castor.codehaus.org
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
