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

[Marco B. <m.b...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastien Bigaret wrote:
|         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 ;)

No problem :)

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

No, I was assuming the bind_saveChanges_to_zope_transactions behaviour.

| 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 ;)

I disagree.

Zope itself uses a conflict resolution approach, where, aside from
interactions with the RDB, you can have ConflictErrors, which are
raised, catched by the ZPublisher which redo the transaction from the
beginning.

| Seriously, it's possible to build a whole application on this principle.

[...]

This is a point which is very interesting to me. However, I think you
could be very limited on what you can use inside Zope... ZCatalogs, for
example, should be exluded, because they can easily generate
ReadConflictError.

However, I suspect you have much more experience on this topic than me,
and I would appreciate your point of view.

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

Of course, my wording was not that good. If I have 1000 users active, I
have 1000 sessions, with 1000 EC. I could have to notify to 999 EC when
one makes a change... or not?

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

I would be happy to contribute something on this point...

| -- Sébastien.

Regards
Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBJFkLXhfyAQQVoaIRAt3DAJ9hGUCP0LE821psO9UZSQip8dsVBQCfcwYX
0crnvRdxieb384XpvloS+fg=
=j+Jq
-----END PGP SIGNATURE-----