RE: AW: AW: Fw: GPL / LGPL

On Wed, 2005-06-29 at 17:33 -0400, Moreau, Christopher wrote:
> 1 more question then.  Are read lock requests queued equally with write
> lock requests?

Yes.

>   In other words, if new read lock requests keep coming
> in, will my write lock request ever happen?

No

Those were 2 question... ;-)

> 
> 
> Respectfully,
>  
> Chris Moreau
>  
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Leo
> Mekenkamp
> Sent: Wednesday, June 29, 2005 1:14 PM
> To: Ozone Users
> Cc: Christian Merenda
> Subject: Re: AW: AW: [Ozone-users] 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
> _______________________________________________
> Ozone-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ozone-users
> 
> 
> 
> -------------------------------------------------------
> 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_idt77&alloc_id492&opk
> _______________________________________________
> Ozone-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ozone-users
> 
> 



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