>>>The mechanism that you propose will assume that you can (and will have
to)
>>lock access to all nodes, whenever one of the nodes is written to!?
>Nope. Timestamps can be used to resolve that. This will, of course, only
>work with CMP where you can have control over how database tables are
>created (to include timestamp columns).
Much, if not most of this has been covered by the database vendors, and the
widely available theory and implementations to view.
imnsho timestamps suck, having used them before, and you'll find these
mostly in systems were locking is not at a fine grained level. another
popluar style is a "library type" mechanism, which is used for long
transactions, as you'd expect to find where data is used at a macro level
(GIS). I'm a little intrigued by some of the JDO stuff that uses hashes to
compare the previous and current states of the data (without requesting bozo
or magic columns that may not have the desired precision required). The
down side is that it assumes the persistence layer is doing some reasonable
caching of the data, or at the very minimum of the hash when the object was
loaded.
For clarity, as there seems to be lots of terms used somewhat ambiguously, a
"dirty-read" is when a new reader retrieves data that has been modified, but
not yet committed. This is differnt than a stale or "consistent" read.
Consistent, is getting the committed value of the data as it existed at the
time the reader requested it. Many persistence layers do this so that
readers don't block writers, and writers don't block readers ... this
becomes much more complicated to implement for long running queries, but
very useful when dealing with such things as financial data.
Thor HW
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
