Re: AW: AW: Fw: GPL / LGPL

On Tue, 2005-06-28 at 00:02 +0200, Per Nyfelt wrote:
> > Ok, your objects reside on the server side. But what about the isolation
> > level? 
> 
> > What about concurrent access to these server-side objects? Do you 
> > have server-side replicas in order to realize optimistic locking strategies
> > or do you work with an pessimistic approach which simply denies concurrent
> > changes until the object is released by the first transaction?
> 
> Pessimistic locking is used.
> 
> >
> > What is your isolation level?
> 
> Not sure about non-repeatable and serailizable but definitely not allowing 
> dirty reads. Maybe Leo, Wieslaw or Falko could share some light on this?

An object can be in 3 different states: not locked, read locked, write
locked.

When an object O1 is not locked, any transaction can get a lock on O1,
either read or write.

When an object O1 is read locked by transaction T0..Tn (n>=0), any
transaction Tn+1 can get a read lock on O1.

When an object O1 is read locked by a transaction T1 (and no other
transaction), then only transaction T1 can get a write-lock on O1. (so
when multiple transactions hold a read lock, no transaction can get a
write-lock)

When an object O1 is write-locked by transaction T1, no other
transaction can get a lock on O1.

A transaction can only unlock an object by committing or aborting.

When a transaction tries to aquire a lock, it gets it immediately if and
only if all above rules are obeyed. If the rules above cannot be obeyed,
the transaction waits until these rules can be obeyed, or aborts when a
deadlock occurs.

Hope this helps...

Cheers,
Leo



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click