Re: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[Thomas M. <tho...@ho...>]

Hi David!

"Dixon-Peugh, David" wrote:

> Good evening.
>
> I've been doing some work on ObJectBridge, and have made some
> further progress.

Thanks for all your efforts!

> First a note on CVS.
>
> When I tried to connect to CVS from home, I was unable to get
> to the "ojb" directory of ObJectBridge.  I dropped some work into
> the "objectbridge" directory.  I've moved just about everything
> that has been updated to "objectbridge" from "ojb" (as I can
> get to both at work, but only one at home.)
>

David, I still have trouble with my WinCVS / SSH configuration. Reading stuff
from the repository to my local disk works fine, but I just don't manage to
get write access. Something with my SSH configuration must be wrong. I spend
several day's reading manuals, downloading sevral ssh implementations --
without success.Now I don't have any ideas what could be wrong. Can you help
me a little ?
Do you work with WinCVS / SSH ?
I have finished some improvements to the PersistenceBroker. But since I can't
check my stuff in. I think distributing another tarball is not an option,
since we are working under CVS conditions now. So I have to stick to the
rules...

>
> Now, as for the changes:
>
> ojb.server.ReaderWriterLock -
>
> This class implements a ReaderWriterLock on an object.  Unfortunately,
> we cannot enforce this lock (its up to the user to do that.)  There are
> basically a couple of APIs:
>         read( Trans )
>         write( Trans )
>         upgrade( Trans )
>         release( Trans )
>
> Right now, the locks are maintained in the TransactionImpl (wrong place,
> should probably be in a LockManager or such.)
>

I had a look at your code and it looks quite promising! Do you have
experiences with systems using this multiple readers or exactly one writer
scheme ?
I had the chance to work with Objectivity DB they have a interesting
alternative strategy:
Multiple Readers and possibly One Writer (they call it MROW). I.E. you can get
a write lock even when there are some readers yet. And you can obtain a read
lock when another transaction has a write lock.

This strategy reduces locking situations when using long transaction. But it
has a large disadvantage: when you want to upgrade a lock from read to write
another tx might have modified the object (with or without a commit). These
lock invalidations are signalled via exceptions to the client and have to
dealed with in the user code.
So maybe it is the best choice to use your exclusive strategy (is there a
special name for it?) until we have more experiences with the system.

You are right we need a separate LockManager class.

>
> ojb.server.ObjectTransactionWrapper -
>
> This class maintains the state of a persistent object at the begining and
> end of a transaction.  When the wrapper is aborted, the persistent fields
> of the object are restored to what they were at the begining of the
> transaction.
>

Wow, you are reusing my ClassDescriptor / FieldDescriptor stuff! looks great.

>
> ojb.server.TransactionImpl -
>
> This class has been modified to use the Reader/Writer locks as apropriate.
> It has also been modified to build ObjectTransactionWrapper around all
> objects
> that a WRITE lock is acquired on.

When I get your code right, you want the user to explicitely aquire read and
write locks ?
My suggestion: use TransactionImpl::markModified() to aquire a write lock
implicitely. Thus the user has not to care about locking but can just call a
setter. Of course the possible LockNotGrantedExceptions have to be reached
back to the user.
What do you think?

Getting implicit read locks maybe not so easy? Perhaps we have to place a
Transaction::lock(ObjectToRead, Transaction.READ) in all getters?

>
>
> It has been modified to have ObjectTransactionWrapper commit/abort where
> apropriate.

Your ObjectTransactionWrapper::comit() is still empty, do you want to reuse my
ObjectModification / ModificationState stuff or do you have other ideas for
triggering the adequate PersistenceBroker calls?

>
>
> ojb.server.TransactionAware -
>
> This is an interface that the end-user can implement.  With the
> TransactionAware iface,
> you can kill a transaction which involves your object.  You can also clean
> up in
> the event of an abort.
>

Good to give usere the ability to interact with the Transaction mechanism.

>
> Share and Enjoy!
>
> David.

All your code looks quite promising!

I've been silently working on improvements of the PersistenceBroker in the
last 2 weeks. I introduced configurable Connection pooling, which gave a real
performance boost.
I was also experimenting with using the PersistenceBroker in J2EE Entitiy
Beans (Bean Managed Persitence right now). These experiments produced
interesting results: using BMP with ObJectBridge as O/R layer increased
performance by a factor 2 - 5 over CMP (using IBM WebSphere and IBMs VAP
Persistence layer).
These positive results have 3 main reasons:
- The ObjectCache
- Smart Updating techniques using ObjectModifications
- I extended the PersistenceBroker interface by
getPkEnumerationByConstraints(...) which is quite helpful in building
ejbFindByXXX methods.
I will repeat my tests with improved diagnostics and will inform you about the
results.

Do you know JDO (Java Data Objects), the new SUN spec for Java-persistence.
Last weekend I heared of it for the first time. In some respects it seems to
be a succecessor to ODMG.
I also discovered CASTOR, and open source project by EXOLAB. They have
implemented JDO. quite interesting approach. There are some similarities to
ObJectBridge, but their code is much more complex than ours and they are
already at release 0.8.9 !

They have a lot of interesting concepts (E.g. an OQL implementation... which
could be helpful for us)

best regards,

Thomas