Long transactions and conflict errors
Hi, During a long transaction that reads lots of ZODB objects in order to generate a report, I get Conflict Errors, which is not a suprise as other users keep accessing some of the same objects. I would like to know if during a transaction there is a way to "unlock" objects from which I read some values but that I don't need anymore for the rest of the transaction execution. Thanks. Pascal ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
--On Dienstag, 1. März 2005 10:10 Uhr +0100 Pascal Peregrina <Pperegrina@Lastminute.com> wrote:
I would like to know if during a transaction there is a way to "unlock" objects from which I read some values but that I don't need anymore for the rest of the transaction execution.
Unlikely. -aj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pascal Peregrina wrote: | Hi, | | During a long transaction that reads lots of ZODB objects in order to | generate a report, I get Conflict Errors, which is not a suprise as other | users keep accessing some of the same objects. | | I would like to know if during a transaction there is a way to "unlock" | objects from which I read some values but that I don't need anymore for the | rest of the transaction execution. ZODB 3.3 attacks this problem using "multi-version concurrency control", ~ which allows for "generational reads" of objects as they were at the start of the transaaction. MVCC eliminates the classic ReadConflict problem, because all reads are made from a transactionally-consistent timepoint. ZODB 3.3 is available from SVN, or as part of one of the Zope 2.8 alphas. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJH1WGqWXf00rNCgRAsn0AJ9UmaUGlR1dxBBSPRoOqq3qagnlpgCbBY6u y5Xz6/PWbYoCPodzL6A1F6A= =Akz8 -----END PGP SIGNATURE-----
ZODB 3.3 is available from SVN, or as part of one of the Zope 2.8 alphas.
Or via one of the 3.3-line standalone release packages: http://www.zope.org/Products/ZODB3.3/ Can't be used with a Zope before the 2.8 line. I expect that before Zope 2.8 final is released, it will move to ZODB 3.4 (and Zope3 already uses a 3.4 development version, because Zope3 relies on new-in-3.4 features, like IFBTrees (int->float)).
Pascal Peregrina wrote at 2005-3-1 10:10 +0100:
... I would like to know if during a transaction there is a way to "unlock" objects from which I read some values but that I don't need anymore for the rest of the transaction execution.
There is no need to "unlock" anything because the ZODB does not lock anything. There are two kinds of "ConflictError": (write) "ConflictError" and "ReadConflictError". You get a "ReadConflictError", when you load an object from the ZODB (into memory) and this object was modified since transaction start by another committed transaction. You can try to minimize such conflicts by reading as early as possible. You get a (write) "ConflictError" when two transactions try to modify the same object -- more precisely, the second transaction gets this error. You can minimize this kind of error by reading as last as possible (but this increases "ReadConflictError" probability). -- Dieter
participants (5)
-
Andreas Jung -
Dieter Maurer -
Pascal Peregrina -
Tim Peters -
Tres Seaver