[T2-users] X [Dbix-class] Live object index support ported

[Sam Vilain]

On Sun, 2005-08-14 at 18:00 +0000, Jean-Louis Leroy wrote:
> > However, it is a bad idea to keep these objects around after you commit,
> > unless you are very careful to implement some kind of object versioning
> > system (ie, each record has a version number that must match before
> > updating can succeed).
> That's exactly what we had in the Appeal Court Automation Project,
> where Tangram was born back in 1996. It was implemented in a subclass
> of Storage - if memory serves. All UPDATES were complemented with a
> ' AND version = xxx'; if the modified rowcount was zero an exception
> was thrown and the Controllers suggested a refresh to the user. I
> think there must still exist a 'refresh' or 'reload' method somewhere
> in T2...

I wonder if this alone is enough to guarantee ACID compliance.

One of the very important things that your database does is that make
sure none of the records that you accessed in a transaction change by a
completed commit between the time your transaction starts to when it
ended, just in case that information influenced the operation.  Or, at
least they do if you SET TRANSACTION LEVEL ISOLATED (or whatever).

Remember, the guiding rule for strict ACID conformance is that the
database should always behave like the transactions going in are
happening in single file, in commit order.

If you rely on cached objects, then this breaks that precondition made
by database writers.  The information about which rows are accessed in a
transaction are not available, and only updates to objects (or explicit
refresh requests) will cause the version check.  This may or may not be
a problem for a given application; in other words, the bug still exists,
it is just a lot more subtle.

It is certainly possible to attach tie (or a less intrusive[1] form of
magic, perhaps) to record the first read access of each object after a
tx_start() (SQL BEGIN TRANSACTION), and "refresh" the cache version - or
at the very least, check the version number of the object - so that the
database gets this vital information.

In the mean time, anyone writing applications they want to be able to
audit should probably continue to dump their object cache at the end of
each transaction :).

Sam.

1. See: Pixie::Info on CPAN