[Persistence-sig] A simple Observation API

[Ilia Iourovitski]

If object participate in more than one transaction
concurrently, transaction API shall provide locks.
It should be possible to acquire read/write lock in
the 
same fashion as RDBMS let client lock row 
using select for update.
In number of cases without locks pure transactions
doesn't garantee concurrency control without problem.
Typical example is user account balance wich can be
updated by user through the web and at the same time
by
monthly batch process.

Ilia

--- Shane Hathaway <shane@zope.com> wrote:
> On 31 Jul 2002, Sebastien Bigaret wrote:
> 
> >   ...I can't decide whether you are talking about
> initialization of a
> >   transaction _instance_. The last sentence
> suggests that participants
> >   are unregistered when the transaction closes: do
> you mean destroyed,
> >   or commit/rollback time? If this is the latter
> case, then I guess I
> >   have missed something, since I cannot find any
> references in the
> >   previous threads about participants being
> unregistered at that
> >   point. If this is the first case (hence, making
> it possible to
> >   generate a given set of DataManagers for each
> new transaction), then
> >   my proposal for DM-factories might be
> meaningful.
> 
> The terminology we're using is a little confusing,
> since an object that is
> truly a transaction should probably begin its life
> at the beginning of a
> transaction and, at commit or rollback time, should
> become permanently
> immutable.  It might even be stored in the database.
> 
> But the things we've been calling transactions play
> a role more like
> transaction "coordinators".  As coordinators, they
> might be reused for
> numerous non-overlapping transactions.  If they are
> reused, it makes
> sense to be able to register a permanent transaction
> participant with a
> specific coordinator.
> 
> I think there might a problem, though.  ZODB
> customarily uses one
> transaction coordinator per thread.  But ZODB
> connections are not really
> thread-specific; they may be reused in a different
> thread when they are
> opened or closed.  So if, for example, you
> registered a permanent
> transaction participant that cleared the cache of a
> specific ZODB
> connection, you wouldn't get the effect you wanted!
> :-)
> 
> That's why I suggested that if you want permanent
> participants, that
> perhaps you'd really want to register the
> transaction participant for all
> threads.  It requires you to consider thread safety,
> but I think you'd
> frequently have to consider that anyway.
> 
> Shane
> 
> 
> _______________________________________________
> Persistence-sig mailing list
> Persistence-sig@python.org
>
http://mail.python.org/mailman-21/listinfo/persistence-sig


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com