On Wed, 2004-01-07 at 10:08, Oliver Zeigermann wrote:
I had a lock a your GenericLocks, and I'd like to see TLocks replaced by
your implementation. As far as I understand, GenericLocks with
maxLevel=2 can emulate TLocks, so why not dump the special-case
implementation?
You mentioned priorities ... does that mean, e.g. that threads waiting
for read-locks should wake up before threads waiting before write-locks?
That's not implemented in TLocks either, so that's not a reason to keep
TLocks either.
What's your favorite book about all this? I need some background about
isolation levels ... (I picked ReadWrite locks from Concurrent
Programming in Java, Design principles and patterns, I like this book)
Michael
> Michael Hartmeier wrote:
>
> > Aaaarghhh! Your code looks definitely better than mine ...
>
> As I said my code in GenericLock was wrong as well! It does not seem to
> be that easy... I will take over the corrected for loop stated below...
>
> > Where did you checkin your GenericLock? We should change ParentStore to
> > use your lock (or even better: use a common lock manager).
>
> Well, as it seems we do not need this locking in the ParentStore any
> more. Still it might be a good idea to use the read/write lock idea from
> TLock. GenericLock is needed for the file store and does well without
> priorities. But - as it seems - caching will need non-blocking locks to
> support isolation levels higher than READ COMMITTED. read/write locks
> would be nice for this...
>
> Locks are in org.apache.slide.util.locking{.impl}... When you have a
> look at it, have in mind GenericLock is a multi level lock, i.e. there
> is at most *one* multi level lock per resource, but the lock itself can
> have more than one lock level and more than one owner. This is a bit
> excentric, but I saw it fit just right...
>
> Oliver
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
