[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Re: Long-running transactions in Ozone?
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?
> > 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.
> > 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). 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 :)
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).
The latter is what I keep thinking must become hairy. Is all this really
implemented already? Using cloning?
> > But if we're already talking per-object locking, the need isn't all that
> > great IMO. Although that raises problems with transaction rollbacks.
> there are no such problems. (see above)
Sorry, that should have read "question". But those are no more...
Thanks for your response.
--
/ Peter Schuller, InfiDyne Technologies HB
PGP userID: 0x5584BD98 or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey@scode.infidyne.com
E-Mail: peter.schuller@infidyne.com Web: http://scode.infidyne.com