In addition to what Ralf has said, please note that loading objects as
read-only mode (in one way or the other) will help you improving
performance as Castor will perform less checks at the end of the
transaction.
In other words, make sure that you know your domain model, especially
when it comes down to categorizations such as 'stability',
'cacheability', etc.
Regards
Werner
Ralf Joachim wrote:
> Hi James,
>
> Castor locks the whole object graph from the time when it gets loaded
> until the end of the transaction which is _db.commit(). If Castor would
> not lock the whole object graph that could lead to inconsistenties. With
> the default access mode 'Shared' these locks are handled by Castor
> internally.
>
> As the transaction at your first example is open during 'some long
> operation' the whole graph gets locked until the end of this transaction.
>
> At the second example you have 2 short transaction. The first one loads
> the object and thereafter releases any locks at first _db.commit().
> According to this no object is locked during the 'some long operation'.
> After that operation you start the second transaction which again loads
> and locks the object including all related ones. Then you do some
> changes to the objects and commit them. At this commit the changes are
> written to database and the locks get released again.
>
> As the objects are not locked during 'some lock operation' at the second
> example, you need to be aware that your object may have changed in the
> meantime.
>
> Hope this helps
> Ralf
>
>
> James Abley schrieb:
>> Hi,
>>
>> I'm trying to understand Castor's locking mechanism for object graphs.
>>
>> Say I have the following classes:
>>
>> class Book {
>>
>> int id;
>>
>> String author;
>>
>> ...
>> }
>>
>> class Customer {
>>
>> int id;
>>
>> // Assume this will be a collection of Books that
>> // has been browsed by each customer.
>> Collection booksBrowsed;
>>
>> // Assume that this is the transaction history of
>> // each customer, so a collection of Transaction
>> // objects
>> Collection transactions;
>>
>> Date lastLoginTime;
>>
>> ...
>> }
>>
>> class Transaction {
>>
>> int id;
>>
>> Date purchaseTime;
>>
>> Book item;
>>
>> ...
>> }
>>
>> If I have client code that does something like the following:
>>
>>
>> Database db = getDatabase();
>> db.begin();
>> db.load(Customer.class, 3, Database.Shared);
>>
>> // do some long operation here
>>
>> customer.setLastLoginTime(Calendar.getInstance().getTime());
>> db.commit();
>> db.close();
>>
>>
>> Is there a lock held on all of the objects in the collections in the
>> Customer object? Or is a lock only obtained on the Customer object when
>> the transaction is ending and Castor can examine each object, see if
>> it's dirty and thus needs to get a lock to update the object?
>>
>> Second related part. I'm very familiar with
>> http://www.castor.org/jdo-best-practice.html, but I was curious about
>> another aspect. Assume that I re-write the client to try to minimize the
>> transaction:
>>
>>
>> Database db = getDatabase();
>> db.begin();
>> db.load(Customer.class, 3, Database.ReadOnly);
>> db.commit();
>> db.close();
>>
>> // do some long operation here
>> db.begin();
>> db.load(Customer.class, 3, Database.Shared);
>> customer.setLastLoginTime(Calendar.getInstance().getTime());
>> db.commit();
>> db.close();
>>
>>
>> Again, what gets locked? Is it the entire object graph, or just the
>> dirty objects?
>>
>> Presumably the latter code sample is the recommended way to go,
>> irrespective of how the object graph gets locked?
>>
>> Cheers,
>>
>> James
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>> http://xircles.codehaus.org/manage_email
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
