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

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

        Hi,

  Since this discussion was pending for a while, I leave here almost the
  whole the context

Marco Bizzarri <m.b...@ic...> wrote:
> 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 ;)
>=20
> No problem :)
>=20
> | 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.
>=20
> No, I was assuming the bind_saveChanges_to_zope_transactions behaviour.

Okay, fine.

> | 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 ;)
>=20
> I disagree.
>=20
> 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.
>=20
> | Seriously, it's possible to build a whole application on this principle.
>=20
> [...]
>=20
> 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.
>=20
> However, I suspect you have much more experience on this topic than me,
> and I would appreciate your point of view.

  Well, AFAIK (Read)ConflictErrors are handled within each storage and
  do not interfere with others --unless that, after the transaction has
  been retried n times, it is abandoned and makes the whole transaction
  fail.

However I can be wrong on this point and have no time to double-check
what I say, so if you have informations suggesting or proving the
contrary I'd be happy to hear from you.


  What I was saying with:

> | Zope does not insist to rely on this if you insist of ignoring
> | its TM ;)

  is that you can build a whole application without binding the DB txns
  (ec.saveChanges()) to zope txns  --and in fact that's exactly what I
  do.  This mean, in particular, that I never worked w/ applications
  where ec.saveChanges() are bound to the zope txn machinery, so I
  cannot be absolutely positive about what I'm saying above.

But some documents, such as TM.py or:
http://www.zope.org/Members/petrilli/WritingADA


  Now, I must double-check the design in ZECSessioning, I think I've
  just see a flaw in it: it should probably implement method tpc_vote()
  calling self.ec.validateChanges(), before any txns is actually
  committed.  Any comment, anyone?


> |>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.
> |
> [...]
>=20
> 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?

  Yes, you do have to --if you don't, then you can get inconsistencies.
  Of course, the notification process is quite fast, and the appropriate
  methods (solving inconsistencies) are only triggered when needed.


> |   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...
>=20
> I would be happy to contribute something on this point...

Great :)

-- S=E9bastien.