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

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



> Correct. It's a pessimistic locking with Multiple Reader One Writer (MROW)
> locks. objects are locked when the are accessed. The lock level (READ, UPDATE,
> WRITE) depends on the lock level that is specified for the method that is
> called. So, if you collect all data of the long transaction in the first part
> of the transaction and call all update methods at once at the end than you only
> have READ locks (which allow multiple readers) most of the time.

Question: So all locking is at a per-object level? I.e., the entire db
doesn't get locked during writes? I thought it was for some reason (probably
because of the use of the word "transaction"). If it's not, that's great.
I'll just do normal Java synchronization on methods / code blocks then.

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?

I was wondering about this; and remembered this E-Mail (that I'm responding
to). We (myself and a few others) are currently using Ozone to build
something that might see some pretty hefty loads (if we're lucky :)). And
DB-wide database locks, while possible to get around, could get problematic
in the long run because it wouldn't scale well with mulitple CPU:s.

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.

But if we're already talking per-object locking, the need isn't all that
great IMO. Although that raises problems with transaction rollbacks.

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