is there a hook for before the transaction is committed
Is there a hook for before the transaction is committed for objects which subclass Persistent? I found __inform_commit__ for a "registered" object, but I can't seem to get that to work as I thought it did. I also tried subclassing TM like a DA, but to no avail. TIA, Tim ___________________________________________________________ Tim McLaughlin BCSwebservices.net Director, Technical Group 1950 Old Gallows Road tel: (703) 790.8081 x111 Suite 201 tim@bcswebservices.net Vienna, VA 22182 www .bcswebservices. net
On Mon, 5 Mar 2001 10:56:38 -0500, Tim McLaughlin <tim@BCSWebservices.net> wrote:
Is there a hook for before the transaction is committed for objects which subclass Persistent?
__getstate__ ? But why would you want that? Toby Dickenson tdickenson@geminidataloggers.com
Hi Tim, I have two suggestions, I hope one of them helps. 1) Attached is a TM.py file that I wrote based on the one you mention below. I've tried to make it more obvious and better documented. 2) Don't use this kind of functionality, but rather use sub-transaction commits. The first suggestion has more overhead than what I assume you would need, but the second one won't work for all situations. A Fishbowl proposal of mine, HashingSupport, was going to use the same kind of hook you are asking about. In this case though, using sub-transaction commits made a lot more sense. In general though, I think that _v_* attributes pose a non-trivial problem that probably requires a hook on abort() if not commit() as well. John Tim McLaughlin wrote:
Is there a hook for before the transaction is committed for objects which subclass Persistent? I found __inform_commit__ for a "registered" object, but I can't seem to get that to work as I thought it did. I also tried subclassing TM like a DA, but to no avail.
TIA, Tim
___________________________________________________________ Tim McLaughlin BCSwebservices.net Director, Technical Group 1950 Old Gallows Road tel: (703) 790.8081 x111 Suite 201 tim@bcswebservices.net Vienna, VA 22182 www .bcswebservices. net
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | jheintz@isogen.com w w w . d a t a c h a n n e l . c o m ############################################################################## # # Zope Public License (ZPL) Version 1.0 # ------------------------------------- # # Copyright (c) Digital Creations. All rights reserved. # # This license has been certified as Open Source(tm). # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are # met: # # 1. Redistributions in source code must retain the above copyright # notice, this list of conditions, and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions, and the following disclaimer in # the documentation and/or other materials provided with the # distribution. # # 3. Digital Creations requests that attribution be given to Zope # in any manner possible. Zope includes a "Powered by Zope" # button that is installed by default. While it is not a license # violation to remove this button, it is requested that the # attribution remain. A significant investment has been put # into Zope, and this effort will continue if the Zope community # continues to grow. This is one way to assure that growth. # # 4. All advertising materials and documentation mentioning # features derived from or use of this software must display # the following acknowledgement: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # # In the event that the product being advertised includes an # intact Zope distribution (with copyright and license included) # then this clause is waived. # # 5. Names associated with Zope or Digital Creations must not be used to # endorse or promote products derived from this software without # prior written permission from Digital Creations. # # 6. Modified redistributions of any form whatsoever must retain # the following acknowledgment: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # # Intact (re-)distributions of any official Zope release do not # require an external acknowledgement. # # 7. Modifications are encouraged but must be packaged separately as # patches to official Zope releases. Distributions that do not # clearly separate the patches from the original work must be clearly # labeled as unofficial distributions. Modifications which do not # carry the name Zope may be packaged in any form, as long as they # conform to all of the clauses above. # # # Disclaimer # # THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY # EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR ITS # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, # SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT # LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF # USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND # ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT # OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # # This software consists of contributions made by Digital Creations and # many individuals on behalf of Digital Creations. Specific # attributions are listed in the accompanying credits file. # ############################################################################## """Provide support for linking an external transaction manager with Zope's """ class TM: """Mix-in class that provides transaction management support A sub class should call self._register() whenever it performs any transaction-dependent operations (e.g. sql statements). The sub class will need to override: _begin if necessary _vote to raise an except if necessary _finish to finallize work, _abort to roll-back work """ def _begin(self): """Hook method to begin external transaction. This may be called multiple times,""" pass def _vote(self): """Hook method to vote on success of transaction commit. This will only be called once,""" pass def _finish(self): """Hook method to complete transaction work. This may be called multiple times.""" pass def _abort(self): """Hook method to undo transaction work. This may be called multiple times.""" pass _registered=None class Surrogate: "A ZODB persistent look-alike." def __init__(self, connection): self._p_jar=connection def _register(self): """This method will register a surrogate persistent object with the transaction. This surrogate will include me in the tpc_* two-phase commit process.""" if not self._registered: try: get_transaction().register(TM.Surrogate(self)) self._registered=1 except: import traceback traceback.print_exc() pass def commit(self, *ignored): "We don't need to actually do an storing." pass def tpc_begin(self, *ignored): "Connection method to begin a commit." self._begin() def tpc_vote(self, *ignored): "Connection method to vote on commit success." self._vote() def tpc_finish(self, *ignored): """Connection method to signal commit success. This should *never* fail""" try: self._finish() finally: self._registered=0 def abort(self, *ignored): """Connnection method to signal commit failure. This should *never* fail""" try: self._abort() finally: self._registered=0
John D. Heintz wrote:
Hi Tim,
I have two suggestions, I hope one of them helps.
1) Attached is a TM.py file that I wrote based on the one you mention below. I've tried to make it more obvious and better documented.
2) Don't use this kind of functionality, but rather use sub-transaction commits.
The first suggestion has more overhead than what I assume you would need, but the second one won't work for all situations.
A Fishbowl proposal of mine, HashingSupport, was going to use the same kind of hook you are asking about. In this case though, using sub-transaction commits made a lot more sense.
In general though, I think that _v_* attributes pose a non-trivial problem that probably requires a hook on abort() if not commit() as well.
Take a look at ZPatterns; specifically, the classes Keeper and Kept from ZPatterns/Transactions.py You can see examples of how they are used in DataSkins.py and Rack.py, although there really isn't much to it. I've included the docstrings below. class Keeper: """Resets an object's per-transaction cache attributes at txn boundaries Note that Keepers are created by Kept objects semi-automatically, and there is usually no need to create one manually. A Keeper automatically registers itself with the Zope transaction upon creation, and instructs its Kept client to clear its per-transaction cache at all transaction boundaries. Keeper methods are called only by the Zope transaction, so don't mess with them.""" class Kept(Base): """Thing which has a Keeper to clear its per-transaction cache. Objects derived from Kept should reference the 'self._v_Keeper' attribute whenever they need to flag that they have made changes to their cache that would require it to be cleared. (Note that '_v_Keeper' is an *attribute*, not a method, and so should not be called, just referenced.) Once this has been done, the next transaction state transition that occurs (sub/main transaction commit or abort) will cause the object's Keeper to call for a cache reset. Subclasses of Kept should define a '__per_transaction_cache_attrs__' attribute as a sequence of attributes which they would like to have deleted from their '__dict__' at reset time. """
Hi Steve, ZPatterns is something that is very high on my must investigate list, but I am not doing Zope development, but rather ZODB based development. I'm sure that I can still get lots of good ideas though... My comment below about _v_* attributes is primarily about not using functionality like Keeper or TM, but rather just taking advantage of _v_* attributes for caching purposes. What I would want from caching, volatile variables is to reset only when the object, or more safely the session, has conflicted and needs to be reset. I wouldn't want to take the performance hit for the cases where I have only successful commits on the same Connection cache of objects. In that case I would needlessly be reseting my volatile cache. In our code we are overriding _p_deactivate() like this: def __p_deactivate__(self): temp = _v_something Persistent.__p_deactive__(self) _v_something We are only doing this for instance vars that are not sensitive to commit/abort cycles. I think that the ideal situation would allow the volative cache to be reset only in the case of a Conflict, i.e. abort() There are two scopes that this can happen at: 1) The _v_* vars that are only local to the Persistent object that they are defined within. This would be a __p_reset__() method or something that is called by the ZODB Connection mechanism. 2) Session wide, i.e. _v_* vars that are dependent on multi-object state but happen to be stored on one of the Persistent objects. This would be handled by Keeper or TM like solutions. Anyway, this is just my current mental state dump. ;-) Thanks, John Steve Alexander wrote:
John D. Heintz wrote:
Hi Tim,
I have two suggestions, I hope one of them helps.
1) Attached is a TM.py file that I wrote based on the one you mention below. I've tried to make it more obvious and better documented.
2) Don't use this kind of functionality, but rather use sub-transaction commits.
The first suggestion has more overhead than what I assume you would need, but the second one won't work for all situations.
A Fishbowl proposal of mine, HashingSupport, was going to use the same kind of hook you are asking about. In this case though, using sub-transaction commits made a lot more sense.
In general though, I think that _v_* attributes pose a non-trivial problem that probably requires a hook on abort() if not commit() as well.
Take a look at ZPatterns; specifically, the classes Keeper and Kept from ZPatterns/Transactions.py
You can see examples of how they are used in DataSkins.py and Rack.py, although there really isn't much to it.
I've included the docstrings below.
class Keeper: """Resets an object's per-transaction cache attributes at txn boundaries Note that Keepers are created by Kept objects semi-automatically, and there is usually no need to create one manually. A Keeper automatically registers itself with the Zope transaction upon creation, and instructs its Kept client to clear its per-transaction cache at all transaction boundaries. Keeper methods are called only by the Zope transaction, so don't mess with them."""
class Kept(Base): """Thing which has a Keeper to clear its per-transaction cache.
Objects derived from Kept should reference the 'self._v_Keeper' attribute whenever they need to flag that they have made changes to their cache that would require it to be cleared. (Note that '_v_Keeper' is an *attribute*, not a method, and so should not be called, just referenced.)
Once this has been done, the next transaction state transition that occurs (sub/main transaction commit or abort) will cause the object's Keeper to call for a cache reset.
Subclasses of Kept should define a '__per_transaction_cache_attrs__' attribute as a sequence of attributes which they would like to have deleted from their '__dict__' at reset time. """
-- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | jheintz@isogen.com w w w . d a t a c h a n n e l . c o m
participants (4)
-
John D. Heintz -
Steve Alexander -
Tim McLaughlin -
Toby Dickenson