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

[David Dixon-P. <dp...@mi...>]

Thomas Mahler wrote:

> 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...
>

I do work withWinCVS / SSH a little bit.  But I just futzed with it and it
worked.
No idea why.  I don't really have any insights as to why mine works and yours
doesn't.

>
> >
> > 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.

Actually, I don't have much experience using Reader/Writer.  I just investigated/

coded that class.

As for MROW, you end up with an isolation problem.  If you are in the process of
reading an object which is being written to, you end up with the wrong data.  (I
believe
Oracle calls it dirty reads.)

The problem here though, is that the user of ObJectBridge is writing the classes
themselves.  The code required to keep the reads and writes seperate needs to
happen in the class.  We cannot provide it within ObJectBridge.

This brings up an interesting flaw, that I can't see any way to get around.  We
cannot
enforce the READ/WRITE locks on objects that ObJectBridge serves up.  So, if you
have a read lock, you can still modify the object.  (Opens the door for many a
race
condition for poorly written code.)


>
> >
> > 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?
>

I would like the user to explicitely get WRITE locks.  READ locks can be granted
when we serve up the object.  (Maybe we can serve up the READ locks in the
implementation of DList or such.)

From what I've seen of the ODMG spec, we need to provide explicit locking
capabilities anyways, so getting a WRITE lock like that isn't such a big deal.


>
> >
> >
> > 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?
>

At this point, ObjectTransactionWrapper is only responsible for the in memory
version
of the object.  The Object is in its commited form when the transaction is
commited,
hense no code.

I'm not sure if putting the storage stuff into the ObjectTransactionWrapper is
necessarily
a good idea.  Ultimately, all objects from the same database need to be committed
within
the same database transaction, and it seems unlilkely that the
ObjectTransactionWrapper
can identify which transaction to commit it in without some big ugly hack.

I am definitely open to suggestions on how we can merge these operations though.

>
> >
> >
> > 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
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/mailman/listinfo/objectbridge-developers

As for CASTOR, I think I ran across them once, but didn't look much further.
This is also the
first I've heard of JDO.

I'll take a look at each of them, and see what I can steal for the transaction
implementation.
(Or even the OQL implementation, which I would really like to give a shot, but
don't have a
starting point yet.)

Thanks,

David