Re: How the transactions are done in the saveChanges?
Sebastien Bigaret <[email protected]> Wed, 18 Aug 2004 22:14:33 +0200
| Newsgroups | gmane.comp.python.modeling |
|---|---|
| Message-ID | <[email protected]> |
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.
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285