[Persistence-sig] A simple Observation API

[Sebastien Bigaret]

> Phillip> (snip)
> Phillip> Also, I think a different method should be used for the
> Phillip> second prepare() call - perhaps a flush() method.  That way,
> Phillip> prepare() won't need to be able to be called twice during the
> Phillip> same commit, which I can see some problems with.  prepare()
> Phillip> could simply call flush(), or perhaps the transaction could
> Phillip> do it.  flush() should be written so as to be usable at any
> Phillip> point in the transaction, since it'll presumably be used to
> Phillip> implement savepoints as well, and in some cases to ensure an
> Phillip> underlying DB is up-to-date before performing a query.

Shane> Yes, flush() is a good idea.  It keeps the phase change
Shane> distinct from the repeatable messages, and its purpose would be
Shane> well understood.

+1, this sounds good.

Shane> Now, I wonder about multithreaded apps.  If you join a
Shane> transaction permanently, do you join all threads?  At first I
Shane> wasn't thinking you would, but on further reflection, it seems
Shane> like that's what you'd want.  And how would this affect CORBA
Shane> (since, from what I hear, its transactions are not bound to
Shane> threads)?

Could you be more explicit? It seems strange to me. For me and the
applications I usually address, DataManagers are most of the time
bound to a ``session'' idea (just like Sessions in Zope or in any
http-based app., i.e. a set of objects being modified by subsequent
requests from users until it reaches the point where it needs to be
made persistent, independently from each other).

  --> What do you think of making it possible for DM-factories to
permanently join transactions, so that it is possible to do whatever
can be accurate for a given situation/application ? (e.g. w/ factories
returning a singleton if you want to join all threads, or a
session-specific DM, or thread-specific DM if you need to, etc.)

  NB: just before posting I have a doubt on what you're actually
  talking about. I know I'm mixing MT and sessions in a unreasonable
  manner hereabove, but the point is that I'm basically thinking
  'joining' in terms of 'initialization of a transaction's
  participants'. Maybe I misunderstood the whole stuff here. Philipp
  wrote about this:

Phillip> * The need for participants to join every transaction.  This
Phillip> is one of my top complaints about the existing API.  I have
Phillip> *never* had a single application where I couldn't simply
Phillip> register all participants to the transactions at or near
Phillip> startup, and never need to do so again -- if it weren't for
Phillip> the fact that the transaction API doesn't work that way.  I
Phillip> have to write code that tracks whether an object has been
Phillip> registered with *this* transaction, and knows when the
Phillip> transaction is over so that it knows it needs to register
Phillip> again

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

-- Sebastien.