[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:
> > 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? 
The StoreManager decides (and implements) the lock policy. ClassicStore (does
not work currently) did actually lock each single object. WizardStore (default
today) locks per cluster. 

> 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.
Since ozone manages locks/concurrency/transactions for you you should not (must
not) do normal Java synchronization in database objects.

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

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

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.

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

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


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