[ODMG] lock progagation flag?

[Phil Warrick]

Hello all,

The problem of lock propagation into a large graph was addressed a month or so ago by adding the ImplicitLocking flag to OJB.properties. When set to false all locking must be done explicitly. This helped me overcome an obstacle when I first began experimenting with OJB where a simple query for one object would take an inordinate amount of time.

Now that I've moved beyond querying and begun writing objects it has become apparent that implicit locking is very useful when constructing even a modest-sized object graph in a transaction. In my case however, this constructed graph has references to a large, infrequently updated graph that I cannot allow locks (even read locks) to propagate into. I would like therefore to have a means to control lock propagation.

I experimented with this sort of configurable locking with a quick-and-dirty hack and it worked very nicely for me: I had the benefit of implicit locking without the overhead of large graph locking.

As a real solution, one approach would be to add a standard flag (rather than a custom one) to the repository for reference and collection descriptors similar to:

<reference-descriptor name="refA"
class-ref="org.acme.A">
<foreignkey field-id-ref="8"/>
<propagateLocks="false">
</reference-descriptor>

<collection-descriptor
name="Bs"
element-class-ref="org.acme.B"
proxy="false"
auto-retrieve="true"
auto-update="false"
propagateLocks="false"
>
<inverse-foreignkey field-id-ref="2"/>
</collection-descriptor>

Then a single check would occur in org.apache.ojb.odmg.TransactionImpl.lockCollections() (and similarly in lockReferences():

private void lockCollections(ClassDescriptor cld, Object newTxObject, int lockMode)
throws IllegalAccessException, PersistenceBrokerException
{
Iterator i;
i = cld.getCollectionDescriptors().iterator();
while (i.hasNext())
{
CollectionDescriptor cds = (CollectionDescriptor) i.next();
if (!cds.doPropagateLocks())
{
continue;
}
...
}
...
}

Does this make sense to anyone? Would you be agreeable to incorporating functionality along these lines? I could submit the changes on the latest cvs head for your perusal if you like.

Thanks,

Phil


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>