Re: [Modeling-users] How the transactions are done in the saveChanges?

[Sebastien B. <sbi...@us...>]

        Hi,

To all: I'll probably be off for a day or two from now, so 
do not expect me to answer quickly in this period ;)

Marco Bizzarri wrote:
> Pfeeww... I didn't expect such a looong answer... :)

This will be very short one, before a more complete in the coming days.
I just want to correct something quickly:

[...]
> In a web environment, like Zope or whatever, you've a clear 
> distinction of a transaction: the arrive of a request, the 
> sending of response. All inside these two events can be 
> considered a transaction; at least, this is what the user can 
> perceive as a transaction.
[...]
> | Back on this, just a few words: having a single 
> BEGIN/COMMIT or ABORT 
> | per zope transaction means that you want to restrict what the 
> | framework is able to do. Updates in an EC can take more 
> than one zope 
> | transaction to be achieved, for example if they are saved after 
> | several html pages have been served one after the other (think of a 
> | wizard, at the end of which you confirm or cancel the changes).
> 
> I don't think this is possible in the current integration of 
> MDL and Zope.
> 
> IIRC, MDL register itself with the _finish method...
> 
> ~  def _finish(self):
> ~    self.ec.lock()
> ~    self.ec.saveChanges()
> ~    self.ec.unlock()
> 
> Now, this means that, at the end of *each* Zope transaction 
> you will do a saveChanges on your ec. Therefore, if you 
> update your objects inside the page of the wizard, they will 
> be stored on the RDB.


No, a session's EC is NOT bound by default to the zope TM, 
(even if the _finish() method is used when it is bound to it)
cf. section 6.4. & 6.4.1 in the User's Guide.  If you observed
the oppposite this is definitely a bug that should be fixed.

So, basically, you should get exactly what you describe:
> The above behaviour could be configurable. You could have an 
> "auto-commit" EC and a "non-auto-commit" EC (i.e. different 
> subclasses), and let the developer choose according to its need.

based on the ZEditingContextSessioning's property 
'bind_saveChanges_to_zope_transactions'. It IS possible to 
decorrelate EC.saveChanges() and the zope TM, it should even
be the default (or, I repeat, this is definitely a bug).

[...]
> Also, even though you could in principle do some 
> saveChanges() by yourself, this would be looking for havoc. 
> Indeed, Zope relies on the fact that a transaction can be 
> redone from the start, if something goes wrong.

Zope does not insist to rely on this if you insist of ignoring
its TM ;) 
Seriously, it's possible to build a whole application on this principle.
E.g. you can design a whole application after the MVC model, with the
V/C part being handled by zpt/python Products and the M part being handled
by plain pure-python modules --which saveChanges() at some point, 
completely decorrelated from the zope transaction machinery.  And the whole
zope machinery is then just used for its "regular" application server
(serving pages, load-balancing between threads, handling sessions, etc.)

> I think I should review a little... consider an application 
> where you have a large number of users, 1000, perhaps, each 
> having its own ec... should we notify each user of the changes?

Wow, I only meant notifying the ECs, not the users ;) unless you decide
so, obviously. 

To be clear, in my language, notifications are only a way to inform
the  different ECs so that a (programmatic) decision can be made on what
should be done (merge changes, discard changes, etc.) --see the 
Notification Framework for details!  Just because something has to be
done, even if this "something" ultimately means "do nothing/ignore the
changes" in some situations :)

  Hopefully this succeeds some of my points in the previsou email
  a little clearer. Again, yes, this would be a lot clearer with a tutorial,
  a zope dedicated section and a sample toy application...

-- Sébastien.