Concerning zeo, I do not use it in the developpement plateforme, but there's one in the test and production platformes, so maybe I will face the problem during the test phase. <br>I do not understand : session objects should be unique for each browser, so why are there conflict errors on them ?????
<br><br>>If ZEO cannot reach your product (import it), it cannot run any<br>>conflict resolution. Make sure that the ZEO server setup has access to<br>>those Products that do conflict resolution.<br><br>The product that does conflict resolution is the Transient object (I think it is the session object) , which is
Zope2.9.0/lib/python/Products/Transcience. I think that zeo should see it.<br><br><br><div><span class="gmail_quote">2007/1/25, yacine chaouche <<a href="mailto:yacinechaouche@gmail.com">yacinechaouche@gmail.com</a>>:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span class="q">>Is _p_resolveConflict method of Inceraser executed at all?<br>>I wonder if traceback you see in console is from the
<br>>code you added:<br>>traceback.print_exc(file=stdin)<br>><br>>or it is always shown when there is a conflict error.
<br><br></span><span class="q"><code><br> def _p_resolveConflict(self, old, state1, state2):<br></span> print "called the _p_resolveConflict of the Increaser object",self<span class="q"><br> try:
<br> number = max(old,state1,state2)<br>
except Exception,msg:<br> import traceback<br> traceback.print_exc(file=sys.stdin)<br> return max(old, state1, state2)<br><br></code><br><br></span>Yes, The method was not called. However, the traceback was indeed printed by the print_exc, since there were no tracebacks before I added this line. In fact, as Gabriel Genellina said :
<span class="q"><br><br>>That might provoke a ConflictError, forcing a<br>>transaction abort and the request to be re-tried (up to three times,<br>>silently, then it goes logged).<br><br></span>as well as Pascal Peregrina:
<span class="q"><br><br>>In general, retry is called when a ZODB Conflict Error has happened.
<br>>If I remember well, Zope will silently retry 3 times, and then actually<br>>return an error page showing the Conflict Error.<br><br></span>as the documentation says <a href="http://www.zope.org/Documentation/Books/ZDG/current/ObjectPublishing.stx" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.zope.org/Documentation/Books/ZDG/current/ObjectPublishing.stx</a> :<br><br>"If an unhandled exception is raised during the publishing process, Zope aborts the transaction. As detailed in Chapter 4. Zope handles ConflictErrors by re-trying the request up to three times. This is done with the zpublisher_exception_hook."
<br><br>Thus, I don't think that the traceback is always shown when there's a conflict error.<br><br>So I decided to look into the file suggested by Maciej Wisniowski :<span class="q"><br><br>>You may take a look at lib/python/ZODB/ConflictResolution.py
<br>>method: tryToResolveConflict. There is a call to _p_resolveConflict.<br><br></span>and edited it like this :<br><br><code><br>def tryToResolveConflict(self, oid, committedSerial, oldSerial, newpickle,<br> committedData=''):
<br> # class_tuple, old, committed, newstate = ('',''), 0, 0, 0<br> print "in ConflictResolution.py, called the tryToResolveConflict method with arguments :"<br> print "self",self,"oid",oid.__repr__(),"committedSerial",committedSerial.__repr__(),"oldSerial",oldSerial.__repr__(),"newpickle",newpickle.__repr__(),"committedData",committedData.__repr__()
<br> try:<br> prfactory = PersistentReferenceFactory()<br> file = StringIO(newpickle)<br> unpickler = Unpickler(file)<br> unpickler.find_global = find_global<br> unpickler.persistent_load
= prfactory.persistent_load<br> meta = unpickler.load()<br> if isinstance(meta, tuple):<br> klass = meta[0]<br> newargs = meta[1] or ()<br> if isinstance(klass, tuple):<br>
klass = find_global(*klass)
<br> else:<br> klass = meta<br> newargs = ()<br><br> if klass in _unresolvable:<br> print "klass",klass.__repr__,"is unresolvable"<br> return None
<br>
<br> newstate = unpickler.load()<br> inst = klass.__new__(klass, *newargs)<br> <br> try:<br> resolve = inst._p_resolveConflict<br> except AttributeError:<br> print inst.__repr__,"has no _p_resolveConflict method"
<br> _unresolvable[klass] = 1<br> return None<br><br> old = state(self, oid, oldSerial, prfactory)<br> committed = state(self, oid, committedSerial, prfactory, committedData)<br><br> resolved = resolve(old, committed, newstate)
<br><br> file = StringIO()<br> pickler = Pickler(file,1)<br> pickler.persistent_id = persistent_id<br> pickler.dump(meta)<br> pickler.dump(resolved)<br> print "everything's ok"
<br> return file.getvalue(1)<br> except (ConflictError, BadClassName):<br> print "ConflictError during conflict resolution in tryToResolveConflict, ConflictResolution.py"<br> import traceback<br>
import sys<br> traceback.print_exc(file = sys.stdout)<br> return None<br> except:<br> print "Exception raised in in tryToResolveConflict, ConflictResolution.py"<br> import traceback<br> import sys
<br> traceback.print_exc(file=sys.stdout)<br> # If anything else went wrong, catch it here and avoid passing an<br> # arbitrary exception back to the client. The error here will mask<br> # the original ConflictError. A client can recover from a
<br> # ConflictError, but not necessarily from other errors. But log<br> # the error so that any problems can be fixed.<br> logger.error("Unexpected error", exc_info=True)<br> return None
<br><br></code><br><br>Now let's see what's going on in the console :<br><br><console><br>in ConflictResolution.py, called the tryToResolveConflict method with arguments :<br>self <tempstorage.TemporaryStorage.TemporaryStorage
instance at 0x43fb6aac> oid '\x00\x00\x00\x00\x00\x00\x00\t' committedSerial '\x03k#\x93\x1d\xff\xf5\x11' oldSerial '\x03k#\x91^t\xf1D' newpickle '(cProducts.Transience.Transience\nIncreaser\nq\x01
)tq\x02.J\x88\xa6\xb8E.' committedData ''<br>ConflictError during conflict resolution in tryToResolveConflict, ConflictResolution.py<span class="q"><br>Traceback (most recent call last):<br></span> File "/opt/aef/Zope-
2.9.0/lib/python/ZODB/ConflictResolution.py", line 126, in tryToResolveConflict
<br> old = state(self, oid, oldSerial, prfactory)<br> File "/opt/aef/Zope-2.9.0/lib/python/ZODB/ConflictResolution.py", line 53, in state<br> p = p or self.loadSerial(oid, serial)<br> File "/opt/aef/Zope-
2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 148, in loadSerial<br> raise POSException.ConflictError(oid=oid)<br>ConflictError: database conflict error (oid 0x09)<br><br><comment> the exception is raised up to the publish function, since it has not been catched, and I added up a code to print traceback in the publish function so here it is </comment>
<span class="q"><br><br>exception raised in the publish module, in function publish<br>Traceback (most recent call last):<br> File "/opt/aef/Zope-2.9.0/lib/python/ZPublisher/Publish.py", line 119, in publish<br>
transactions_manager.commit()
<br> File "/opt/aef/Zope-2.9.0//lib/python/Zope2/App/startup.py", line 234, in commit<br> transaction.commit()<br> File "/opt/aef/Zope-2.9.0//lib/python/transaction/_manager.py", line 96, in commit
<br> return self.get().commit(sub, deprecation_wng=False)<br> File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 380, in commit<br> self._saveCommitishError() # This raises!<br> File "/opt/aef/Zope-
2.9.0//lib/python/transaction/_transaction.py", line 378, in commit<br> self._commitResources()<br> File "/opt/aef/Zope-2.9.0//lib/python/transaction/_transaction.py", line 433, in _commitResources<br>
rm.commit(self)<br> File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 484, in commit<br> self._commit(transaction)<br> File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 526, in _commit
<br> self._store_objects(ObjectWriter(obj), transaction)<br> File "/opt/aef/Zope-2.9.0//lib/python/ZODB/Connection.py", line 554, in _store_objects<br> s = self._storage.store(oid, serial, p, self._version, transaction)
<br> File "/opt/aef/Zope-2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 200, in store<br> data=data)<br></span>ConflictError: database conflict error (oid 0x09, class Products.Transience.Transience.Increaser
, serial this txn started with 0x036b23915e74f144 2007-01-25 13:05:22.138314, serial currently committed 0x036b23931dfff511 2007-01-25 13:07:07.031211)<br></console><br><br>The exception is raised, as the traceback says, in File "/opt/aef/Zope-
2.9.0//lib/python/tempstorage/TemporaryStorage.py", line 148, in loadSerial<br> raise POSException.ConflictError(oid=oid)<br><br>Is it normal that the oid, as an argument to tryToResloveConflict, was "\x00\x00\x00\x00\x00\x00\x00\t" then became 0x09 when the exception was raised ?
<br><br>here's the loadSerial code :<br><br><code><br> def loadSerial(self, oid, serial, marker=[]):<br> """ this is only useful to make conflict resolution work. It<br> does not actually implement all the semantics that a revisioning
<br> storage needs! """<br> self._lock_acquire()<br> try:<br> data = self._conflict_cache.get((oid, serial), marker)<br> if data is marker:<br> # XXX Need 2 serialnos to pass them to ConflictError--
<br> # the old and the new<br> raise POSException.ConflictError(oid=oid)<br> else:<br> return data[0] # data here is actually (data, t)<br> finally:<br> self._lock_release()
<br><br></code><br><br><div><span class="gmail_quote">2007/1/25, Martijn Pieters <<a href="mailto:mj@zopatista.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mj@zopatista.com</a>>:
</span><div><span class="e" id="q_11059bb07ed202b9_15"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 1/24/07, Maciej Wisniowski <<a href="mailto:maciej.wisniowski@coig.katowice.pl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">maciej.wisniowski@coig.katowice.pl</a>> wrote:<br>> Another question, do you use ZEO? I know there were some issues
<br>> with _p_resolveConflict and ZEO (at last in Zope
2.8.x). Result<br>> was that with ZEO setup _p_resolveConflict was not called at all.<br>> There is solution for this but I don't know if this is your case<br>> especially that you are dealing with TemporaryStorage which is
<br>> typically managed by ZEO Client...<br><br>If ZEO cannot reach your product (import it), it cannot run any<br>conflict resolution. Make sure that the ZEO server setup has access to<br>those Products that do conflict resolution.
<br><br>--<br>Martijn Pieters<br></blockquote></span></div></div><br>
</blockquote></div><br>