[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Re: Long-running transactions in Ozone?

On Tue, 17 Apr 2001, Peter Schuller wrote:
> Hello,
> 
> > Since ozone manages locks/concurrency/transactions for you you should not (must
> > not) do normal Java synchronization in database objects.
> 
> Hmmm. Ok. But I thought clusters were basically a random grouping of objects
> used in the store?

The WizardStore tries to group objects that 'are used together' together in
clusters. So the chance is high that if you access/lock one object out of a
cluster then you will probably access/lock others from the same cluster too.

> 
> > > And how about roll backs; do they roll back all changes in the transaction
> > > or just the changes in the object that threw the exception?
> > all changes
> 
> Ok; perfect. Thanks!
> 
> > Although ozone does not lock entire DBs or something the scalability on SMP is
> > still a problem. I got good results on 2CPU and only reading. I did not really
> > test update transactions. Anyway, the optimistic locking which were
> > recently dicussed can probably help a lot here.
> 
> Yes, that's what peaked my interest. I wasn't sure if that's what you were
> referring to (full blown optimistic locking in general). I don't quite see
> how it's that simple :)
> 
> How would the problem of maintaining multiple "views" (depending on
> transaction) of the database? Would modified objects be cloned before being
> changed in update transactions? I may be missing something here; but to me
> it looks like it can get pretty hairy.

This depends on the implementation of the optimistic locking you choose. Your
'clone' version indeed is hard to implement (I did it for the first versions of
ozone). It would probably check at the end of a transaction if all READ locks
were aquired before all WRITE locks (2-phase).

I was thinking of an implementation that _immediately_ throws an exception,
when a object which I have optimistcly locked was changed by another party
(READ and WRITE are not 2-phase). For this implementation no clones are needed.
Just a way set/check timestamps.

> 
> > > If it's indeed a complete db lock for writes, it would be desirable to
> > > implement a transaction system similar to what you might find in most RDBMS.
> > > This would probably require quite a bit of work though I suspect; but I'm
> > > definitely willing to look into it, if I can get my head around the
> > > necessary parts of Ozone.
> > it's already there ;)
> 
> Well I was mostly referring to implementing multiple-read and multiple-write
> transactions that do not affect each other (kind of like a SERIALIZABLE
> RDBMS transaction). 
I probably lost you here. We are talking about scalability, right? We want to
let as most threads/CPUs run as possible, right again? SERIALIZABLE gives the
worst scalability IMO. SERIALIZABLE isolation level on RDBMSs let you neither
WRITE nor READ (!) data at the same time from different transactions.


> Hmm. So in spite of update methods not locking the
> entire database (only clusters), we still have transaction isolation? I did
> some digging in the source code about a week ago and I got the impression it
> wasn't all that advanced :)
do it better! ;)

Of course we have transaction isolation. ozone uses MROW locks (pessimistic
locking). This is something like SERIALIZABLE but let multiple readers
access an object.

> 
> How is this solved conceptually? Specifically with regard to crossing
> cluster boundaries where the locking doesn't do everything.
> 
> Not to mention maintaining isolation in a case where write-thread A starts
> modifying cluster X, and when write-thread B (whose transaction started
> prior to write-thread A's) it has to see the old version of X (prior to A's
> modifications).
ozone uses pessimistic locking! Just one tx can WRITE an object at one given
point in time.

> 
> The latter is what I keep thinking must become hairy. Is all this really
> implemented already? Using cloning?
No, using MROW locks, aka pessimistic locking.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com