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

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

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

Ok, that's consistent with what I thought.

I'll quote out of order now because it relates to this:

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

But entire clusters are locked at a time, right?

Anyways; my "problem" then is one of deadlock.

Suppose transaction A needs to access object
X and Z recursively in order to complete. Supposed further that transaction B needs
to access object Y, Z and X recursively in order to complete. Each object is in a
separate cluster. Transaction A executes some update method on object X
simultaneously as a method is being executed on Z by transaction B. This is
allowed because they are in different clusters.

Transaction B proceeds to execute a method on object Z (again, recursively). A
is now working with X and B with Z.

We now have two possiblities.

1) A wants to recursively invoke a method on Z before B wants to recursively
   invoke a method on X.
2) B wants to recursively invoke a method on X before A wants to recursively
   invokte a method on Z.
   
In both cases we have a deadlock situation. A waits on B and B waits on A.
None can complete without breaking transaction isolation.

A: X ---------------> Z ------> ... return
B: Y -----> Z ------> X ------> ... return

                      ^
		      ^
	At this point X is locked by A and Z by B (or rather, their clusters
	are locked).

So what am I missing? If Ozone uses *only* pessimistic locking, and clusters
are the units on which the locking occurrs (rather than the entire DB), how
is this worked around?

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

Hmm. So basically, charge ahead and do changes, and if a read transaction
detects a change, rollback the read transaction (in response to the exception)
and try again? That would impose a one-write-at-a-time restriction though,
would it not?

If that is a correct interpretation, then I suppose that would work well in
most cases. However the absolut worst-case senario is that read transactions
never complete because they keep getting rolled back due to writes.
Particularly in the case of longer transactions.

Then again, I'm probably mis-understanding you. I have no prior experience
with implementing databases (OO or otherwise).

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

Well the way SERIALIZABLE isolation works in Postgres at least (I haven't
actually read the SQL spec so I don't know if its required/correct) is that each
transaction can proceed simultaneously. It's just that transaction X doent't
see what transaction Y is doing, and vice versa.

Essentially, each transaction (even with auto-commit) operates on a snapshot
of the entire database. Changes then get "merged", assuming no conflicts.

(That's just conceptual; obviously it's not implemented like that!)

But yes, the point was scalability, and being able to do mulitple reads and
writes simultaneously (that is, actually executing then simultaneously inside
the database).

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

Yes. My confusion was just due to my (possibly imagined?) deadlock senario.
I assumed something special was being done when cluster boundaries were
crossed.


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