[ZODB-Dev] Reloading product in 2.8
Hello zodb developers!
My product has 'Auto refresh mode' option checked.
I changed some source code of my product, after that autorefresh have been
occured.
And after autorefresh I got strange several errors:
this error was accure almost after all autorefreshs.
1.
2005-07-12 17:44:07 ERROR Zope.SiteErrorLog Error while logging
Traceback (most recent call last):
File C:\Program
Files\Zope-2.8.0-final\lib\python\Products\SiteErrorLog\SiteErrorLog.py, line
195, in raising
log.append({
File C:\Program Files\Zope-2.8.0-final\lib\python\persistent\list.py, line
65, in append
self._p_changed = 1
File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line
838, in register
self._register(obj)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line
848, in _register
self.transaction_manager.get().join(self)
File C:\Program
Files\Zope-2.8.0-final\lib\python\transaction\_transaction.py, line 258, in
join
self._prior_operation_failed() # doesn't return
File C:\Program
Files\Zope-2.8.0-final\lib\python\transaction\_transaction.py, line 252, in
_prior_operation_failed
raise TransactionFailedError(An operation previously failed,
TransactionFailedError: An operation previously failed, with traceback:
File C:\Program
Files\Zope-2.8.0-final\lib\python\ZServer\PubCore\ZServerPublisher.py, line
23, in __init__
response=response)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZPublisher\Publish.py,
line 386, in publish_module
environ, debug, request, response)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZPublisher\Publish.py,
line 187, in publish_module_standard
response = publish(request, module_name, after_list, debug=debug)
File C:\Program
Files\WebSite\Instances\Zope_28\Products\CMFNauTools\Patches.py, line 1341, in
_nau_new_publish
x = Publish.old_publish(request, *args, **kwargs)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZPublisher\Publish.py,
line 119, in publish
transactions_manager.commit()
File C:\Program Files\Zope-2.8.0-final\lib\python\Zope2\App\startup.py,
line 215, in commit
transaction.commit()
File C:\Program Files\Zope-2.8.0-final\lib\python\transaction\_manager.py,
line 84, in commit
self.get().commit(sub)
File C:\Program
Files\Zope-2.8.0-final\lib\python\transaction\_transaction.py, line 382, in
commit
self._saveCommitishError() # This raises!
File C:\Program
Files\Zope-2.8.0-final\lib\python\transaction\_transaction.py, line 380, in
commit
self._commitResources()
File C:\Program
Files\Zope-2.8.0-final\lib\python\transaction\_transaction.py, line 425, in
_commitResources
rm.commit(self)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line
462, in commit
self._commit(transaction)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line
503, in _commit
self._store_objects(ObjectWriter(obj), transaction)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line
534, in _store_objects
self._cache[oid] = obj
ValueError: Cache values may only be in one cache.
and some times
2.
2005-07-12 17:54:25 ERROR Zope.SiteErrorLog Error while loggingTraceback (most
recent call last):
File C:\Program
Files\Zope-2.8.0-final\lib\python\Products\SiteErrorLog\SiteErrorLog.py, line
195, in raising
log.append({
File C:\Program Files\Zope-2.8.0-final\lib\python\persistent\list.py, line
65, in append
self._p_changed = 1
File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line
838, in register
self._register(obj)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line
848, in _register
self.transaction_manager.get().join(self)
File C:\Program
Files\Zope-2.8.0-final\lib\python\transaction\_transaction.py, line 258, in
join
self._prior_operation_failed() # doesn't return
File C:\Program
Files\Zope-2.8.0-final\lib\python\transaction\_transaction.py, line 252, in
_prior_operation_failed
raise TransactionFailedError(An operation previously failed,
TransactionFailedError: An operation previously failed, with traceback:
File C:\Program
Files\Zope-2.8.0-final\lib\python\ZServer\PubCore\ZServerPublisher.py, line
23, in __init__
response=response)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZPublisher\Publish.py,
line 386, in publish_module
environ, debug, request, response)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZPublisher\Publish.py,
line 187, in publish_module_standard
response = publish(request, module_name, after_list, debug=debug)
File C:\Program
Files\WebSite\Instances\Zope_28\Products\CMFNauTools\Patches.py, line 1341, in
_nau_new_publish
x = Publish.old_publish(request, *args, **kwargs)
File C:\Program Files\Zope-2.8.0-final\lib\python\ZPublisher\Publish.py,
line 119, in publish
transactions_manager.commit()
File C:\Program
Re: [ZODB-Dev] zodb connection question
Jürgen Herrmann wrote: [ Jim Fulton wrote:] Jürgen Herrmann wrote: hi all! i'm trying to form a patch that will result in a method _before_commit() being called on each modified object in a transaction (if that method exists of course) right before commit. main sense is to automate/delay (re)cataloging. first i looked at the Transaction class, as there have been heavy modifications to it from zodb 3.2 to 3.4 Patching is generally a bad idea. I suggest creatinga new catalog (by subclassing or adapting an existing one) that: - queues updates - registers a before-commit callback with the TM on the first update in a transaction - processes the queue in the callback I did this recently for with Zope 3's catalog and it worked very well. (I happend to use subclassing and would use adaptation if I were to do it again.) Jim hi jim! thanks for your reply, i already thought about such a solution and discarded it because it would still be necessary to call a method on an object to recatalog it. this step (the programmer's responsibility) i want to eliminate for several reasons. Which are? so, what i need is a way to have my mechanism called before transaction commits (would be possible to use the hooks provided by zodb 3.4 for that, sure) and cycle through all modified objects (that's where the hooks in 3.4 are not enough for me, they don't provide any way to access a list of modified objects). I would oppose a per-object callback mechanism. OTOH, I would not oppose providing enough hooks to allow you to implement such a mechanism yourself without patching ZODB. Note however, that such a mechanism might not help you anyway, as discussed below. as i showed in my first post, the callback to modified objects works as expected, but in the called method i'm not able to acquire the responsible Catalog for the modified object. That's because objects registered are not acquisition wrapped. up to what point can i modify objects in a transaction? why doesn't acquisition on my objects work in Connection::tpc_begin() ??? The objects are not acquisition wrapped. IMO, ZODB is way too low a level to do what you want to do. Note that what you are trying to do would be easier in Zope 3 because Zope 3 relies far less on wrappers for acquisition. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] zodb connection question
[ Jim Fulton wrote:] Jürgen Herrmann wrote: [ Jim Fulton wrote:] Jürgen Herrmann wrote: hi all! i'm trying to form a patch that will result in a method _before_commit() being called on each modified object in a transaction (if that method exists of course) right before commit. main sense is to automate/delay (re)cataloging. first i looked at the Transaction class, as there have been heavy modifications to it from zodb 3.2 to 3.4 Patching is generally a bad idea. I suggest creatinga new catalog (by subclassing or adapting an existing one) that: - queues updates - registers a before-commit callback with the TM on the first update in a transaction - processes the queue in the callback I did this recently for with Zope 3's catalog and it worked very well. (I happend to use subclassing and would use adaptation if I were to do it again.) Jim hi jim! thanks for your reply, i already thought about such a solution and discarded it because it would still be necessary to call a method on an object to recatalog it. this step (the programmer's responsibility) i want to eliminate for several reasons. Which are? i have developed a framework that nicely handles many2many relations, heavily uml based, python code generation for attribute getter/setters, code generation for methods (the def only), automatic index creation... in short, i want to make everything as easy for the programmer (atm only me :) first i had the code generation framework write out an explicit self.reindex_object() at the end of each setter, ugly. it also had the drawback that setting 3 attributes caused the object to reindex itself 3 times. not the best for performance. so, what i need is a way to have my mechanism called before transaction commits (would be possible to use the hooks provided by zodb 3.4 for that, sure) and cycle through all modified objects (that's where the hooks in 3.4 are not enough for me, they don't provide any way to access a list of modified objects). I would oppose a per-object callback mechanism. OTOH, I would not oppose providing enough hooks to allow you to implement such a mechanism yourself without patching ZODB. Note however, that such a mechanism might not help you anyway, as discussed below. as i showed in my first post, the callback to modified objects works as expected, but in the called method i'm not able to acquire the responsible Catalog for the modified object. That's because objects registered are not acquisition wrapped. up to what point can i modify objects in a transaction? why doesn't acquisition on my objects work in Connection::tpc_begin() ??? The objects are not acquisition wrapped. IMO, ZODB is way too low a level to do what you want to do. Note that what you are trying to do would be easier in Zope 3 because Zope 3 relies far less on wrappers for acquisition. Jim oh well, unfortunately i began with that project about 8months ago. that time zope (x)3 was still not recommended to users on the zope mailinglist, so i went for zope2. anyways, there must be a solution to that problem. if zodb is way to low for my approach, where do i get a possibility to get notified about a imminent transaction commit? and how could i find out about the modified objects? another question: would it be possible to wrap the objects to enable acquisition in my first approach? guess i'd have to know the container for that, right (which is no problem, because i have one distinct container folder for each class)? if that works somehow, i'd bug you further to provide me with that hooks you described above :) thanks in advance for your replies... juergen herrmann ___ XLhost.de - eXperts in Linux hosting Juergen Herrmann Weiherweg 10, 93051 Regensburg, Germany Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 ICQ: 27139974 - IRC: [EMAIL PROTECTED] WEB: http://www.XLhost.de ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Savepoints are invalidated once they are used
On 7/12/05, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy Hylton]
IIRC, the old implementation of savepoints kept a copy of the index at
the time the savepoint was taken so that you could rollback to it
multiple times. I don't think there's any way to avoid such a copy.
Right, and the current implementation did that too. The surprise was that
it wasn't enough. Sketch:
1. Modify object 0.
2. Make savepoint 1.
It makes a copy of the current index, say {0: 0}, and remembers
the TmpStore size, say 100.
3. Fiddle around.
4. Rollback to savepoint 1.
This sets the TmpStore index to the saved {0: 0}, and truncatss
TmpStore to size 100. So far so good -- or so it seems.
5. Modify object 0 again, and make savepoint 2.
This changes the TmpStore index to {0: 100}, makes of a copy of
{0: 100} in savepoint 2, and increases TmpStore size to 200. This
just did something horribly wrong too, although it's subtle.
6. Rollback to savepoint 1 again.
Because a copy of savepoint 1's index wasn't _also_ made in
step #4, the index savepoint 1 is holding onto mutated to
{0: 100} during step #5 (object sharing). This (#6) step
leaves TmpStore with (the mutated) index {0: 100} and size 100.
7. Reference object 0.
Oops. The index tells us to seek to pos 100, but TmpStore has
been truncated to 100. We get a low-level exception from
struct.unpack() about not enough bytes to unpack the data record
header.
You can guess that I saw that happening wink. Step #4 also needs to copy
the index (from the savepoint to TmpStore) instead of sharing a reference,
although this wasn't needed so long as a savepoint could be used at most
once (then mutating the savepoint's index after a rollback had no ill
effect, as the savepoint's index could never be referenced again).
I understand. The further invariant is that the index captured when a
savepoint created is immutable.
Jeremy
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Re: Savepoints are invalidated once they are used
[Christian Heimes, suggests changing Transaction.commit() to start with if subtransaction: # TODO deprecate subtransactions self._subtransaction_savepoint = self.savepoint(1) return if self._savepoint2index: self._invalidate_all_savepoints() i.e. swapping the first two blocks] [Jim Fulton] subtransactions != savepoints There is *no* promise of nestability with subtransactions. Committing a subtransaction invalidates prior savepoints by design. This is necessary to maintain backward compatibility. I'm not sure I follow this: old code could not be using savepoints directly, so what would break in code that stuck solely to subtxn commits? The internal savepoint used to implement commit(1) now isn't exposed to users, so they couldn't roll back directly to older subtxn commits, and the transaction internals only remember the (internal) savepoint for the most recent commit(1) done. So I don't see how backward compatibility would be injured. BTW, I tried it, and all the ZODB tests pass with this change. If you don't like this behavior, don't use subtransactions. A good community project would be to convert all of the subtransaction calls in Zope to savepoint calls. Yup. Speaking of which, some of the comments say subtxns are deprecated, but they're not really. It's too late to deprecate them in 3.4 (for 3.6). Is it OK to deprecate them now in 3.5 (for 3.7)? I would like to, and deprecation nags are good motivators. If not 3.5, in 3.6 (for 3.8)? ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] zodb connection question
Jürgen Herrmann wrote: [ Jim Fulton wrote:] Jürgen Herrmann wrote: [ Jim Fulton wrote:] Jürgen Herrmann wrote: hi all! i'm trying to form a patch that will result in a method _before_commit() being called on each modified object in a transaction (if that method exists of course) right before commit. main sense is to automate/delay (re)cataloging. first i looked at the Transaction class, as there have been heavy modifications to it from zodb 3.2 to 3.4 Patching is generally a bad idea. I suggest creatinga new catalog (by subclassing or adapting an existing one) that: - queues updates - registers a before-commit callback with the TM on the first update in a transaction - processes the queue in the callback I did this recently for with Zope 3's catalog and it worked very well. (I happend to use subclassing and would use adaptation if I were to do it again.) Jim hi jim! thanks for your reply, i already thought about such a solution and discarded it because it would still be necessary to call a method on an object to recatalog it. this step (the programmer's responsibility) i want to eliminate for several reasons. Which are? i have developed a framework that nicely handles many2many relations, heavily uml based, python code generation for attribute getter/setters, code generation for methods (the def only), automatic index creation... in short, i want to make everything as easy for the programmer (atm only me :) first i had the code generation framework write out an explicit self.reindex_object() at the end of each setter, ugly. it also had the drawback that setting 3 attributes caused the object to reindex itself 3 times. not the best for performance. If you are generating code, there there should be no problem generating the calls to reindex, or, with Zope 2.8, you can use the Zope 3 event system. which should be cleaner. You can avoid the cost of indexing on each modification by creating a catalog with the queuing strategy I describer earlier. ... if zodb is way to low for my approach, where do i get a possibility to get notified about a imminent transaction commit? and how could i find out about the modified objects? You use events. Have your generated code generate events, which include the content-wrapped objects, when an object is modified. Create an object, such as a specialized catalog or some other object that maintains a modified- object collection. This object tracks which objects have been modified, collapsing modification events for the same object. For the sake of discussion, call this object the modification buffer. Provide a subscriber for modification events that registers objects with the modification buffer. When the buffer gets the first object (in a transaction), it registers itself to be called by the transaction machinery. When it is called, it processes (e.g. catalogs) the objects in its buffer and clears the buffer. another question: would it be possible to wrap the objects to enable acquisition in my first approach? No. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: Savepoints are invalidated once they are used
Tim Peters wrote: [Christian Heimes, suggests changing Transaction.commit() to start with if subtransaction: # TODO deprecate subtransactions self._subtransaction_savepoint = self.savepoint(1) return if self._savepoint2index: self._invalidate_all_savepoints() i.e. swapping the first two blocks] [Jim Fulton] subtransactions != savepoints There is *no* promise of nestability with subtransactions. Committing a subtransaction invalidates prior savepoints by design. This is necessary to maintain backward compatibility. I'm not sure I follow this: old code could not be using savepoints directly, so what would break in code that stuck solely to subtxn commits? ... So I don't see how backward compatibility would be injured. BTW, I tried it, and all the ZODB tests pass with this change. When you so commit(1), the promise is that, if the top-level transaction commits, then any work done up to the commit(1) is committed. Consider this scenario: - new code: s = transaction.savepoint() - old code: foo.x = 42 - old code: transaction.commit(1) - new code: s.rollback() - old code: transaction.commit() Now, the old code expected that foo.x was 42. It did a commit(1). But, in fact, if we can roll back s, then in fact, the old code can't count on the semantics of the commit(1). This would be a change in behavior for subtransactions. Subtransactions only provide one level of nesting. They are not the same as savepoints. Now, I don't know for sure that anyone depends on the non-nestedness of subtransactions. Mostly, subtransactions are used to checkpoint incomplete changes to disk. So perhaps the backward compatibility risk is small. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Re: Savepoints are invalidated once they are used
Jim Fulton wrote: A good community project would be to convert all of the subtransaction calls in Zope to savepoint calls. Done I found commit(1) in Zope3 zope.app.file.file Pdata handling and in code and tests in Zope2. Christian ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Savepoints are invalidated once they are used
[Jeremy Hylton] I understand. The further invariant is that the index captured when a savepoint created is immutable. Or at least acts like it. Copying is an easy-to-code and effective way to ensure that, and I don't know of a better feasible way. Capturing a lot of savepoints (or doing a lot of commit(True)) while modifying a lot of objects makes for a lot of index copying, though, effectively injecting an O(N**2) time drag (even if rollback/abort(True) is never done). A copy on modify flavor of dict could do much better. Since I'm sure Google could also make good use of that, I expect to see a patch on the Python tracker from you implementing that by the end of this weekend wink. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Re: Savepoints are invalidated once they are used
[Jim Fulton] A good community project would be to convert all of the subtransaction calls in Zope to savepoint calls. [Christian Heimes] Done I found commit(1) in Zope3 zope.app.file.file Pdata handling and in code and tests in Zope2. Bless you! Alas, I haven't received any messages from any Zope Corp checkin list since Sunday, so we'll just have to take your word for it wink. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: Savepoints are invalidated once they are used
Tim Peters wrote: Bless you! Alas, I haven't received any messages from any Zope Corp checkin list since Sunday, so we'll just have to take your word for it wink. svn diff -r 33279:33280 \ svn+ssh://svn.zope.org/repos/main/Zope/branches/Zope-2_8-branch ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
On 7/12/05, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 12 Jul 2005, at 13:17, Victor Safronovich wrote: previous Zope version, which I used, was 2.6.1, but it was very old version and I decided to jump to 2.8.0. I took problems with autorefresh. What can I do to solve my problems? If it creates problems then simply don't use it. That's not a very good answer. The refresh functionality has been unstable since it became a part of Zope core, and I have ended up not using it since it since then (So that's what? Since Zope 2.3 or something). I've tried from time to time, but I always end up going back to just restarting Zope every time I make a code change, because refreshing and trying, and often (but not always) getting incomprehensible errors and then restarting Zope, is just much slower that simply restarting Zope every time. That however, is a serious slowdown in the Zope development process, and I would be very happy if this could be made to work stably. But instead of getting better, it seems to deteriorate... I'm all for makeing a serious effort one day to fix this. But I have tried before, and I am way out of depth. Any suggestions of how to solve this problem? Or should be just give up, and mark it as deprecated in 2.8.1, so that people stop thinking it's actually useful? ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
On 12 Jul 2005, at 18:17, Lennart Regebro wrote: previous Zope version, which I used, was 2.6.1, but it was very old version and I decided to jump to 2.8.0. I took problems with autorefresh. What can I do to solve my problems? If it creates problems then simply don't use it. That's not a very good answer. I disagree. Due to the nastiness Refresh has to perform under the cover even Shane has to admit that it simply is not some make development faster panacea. The only viable answer is stop using if it gives you trouble because it is probably impossible to make it work in 100% of all cases. jens ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
On Jul 12, 2005, at 1:46 PM, Jens Vagelpohl wrote: On 12 Jul 2005, at 18:17, Lennart Regebro wrote: previous Zope version, which I used, was 2.6.1, but it was very old version and I decided to jump to 2.8.0. I took problems with autorefresh. What can I do to solve my problems? If it creates problems then simply don't use it. That's not a very good answer. I disagree. I agree with Jens that it is unlikely to ever work correctly 100% of the time. I agree with Lennart that leaving it not working is not a good answer. I think it should be removed as a feature. Making every developer using ZODB eventually learn not to trust the feature seems unnecessarily painful. Gary ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
On 7/12/05, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 12 Jul 2005, at 18:17, Lennart Regebro wrote: previous Zope version, which I used, was 2.6.1, but it was very old version and I decided to jump to 2.8.0. I took problems with autorefresh. What can I do to solve my problems? If it creates problems then simply don't use it. That's not a very good answer. I disagree. Due to the nastiness Refresh has to perform under the cover even Shane has to admit that it simply is not some make development faster panacea. The only viable answer is stop using if it gives you trouble because it is probably impossible to make it work in 100% of all cases. No, that's still not a viable answer, because it should be possible to make some kind of list of cases where it is expected not to work, so that you can try to see if this is one of the cases. The above answer however basically means well, if it happens to work for you, then good luck, but it is actually a piece of unsupported crap that hasn't worked for years and that nobody is bothered to fix bugs in. Imagine if somebody tried to use ZPTs, and the answer to any question where you get errors from it is well, then don't use it? It's just not a viable answer. If it is the majoritys agreement that this answer is the best one, and that the refresh functionality should be looked at as something that may or may not work purely on luck, then I'll mark it as deprecated and up for removal in 2.10. Maybe we can start looking at the last non-integrated version of the software, because it worked much better, and again make it a standalone product? ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Reloading product in 2.8
[Victor Safronovich, having problems with auto refresh] Victor (et alia), I think a discussion of auto-refresh would be more useful on a Zope list -- it's not really (AFAIK) a ZODB issue. This is what changed in ZODB, from ZODB 3.3c1's NEWS file (and no, it won't be changed back to the way it was): - Transactions have new, backward-incompatible behavior in one respect: if a ``Transaction.commit()``, ``Transaction.commit(False)``, or ``Transaction.commit(True)`` raised an exception, prior behavior was that the transaction effectively aborted, and a new transaction began. A primary bad consequence was that, if in a sequence of subtransaction commits, one of the commits failed but the exception was suppressed, all changes up to and including the failing commit were lost, but later subtransaction commits in the sequence got no indication that something had gone wrong, nor did the final (top level) commit. This could easily lead to inconsistent data being committed, from the application's point of view. The new behavior is that a failing commit sticks until explicitly cleared. Now if an exception is raised by a ``commit()`` call (whether subtransaction or top level) on a Transaction object ``T``: - Pending changes are aborted, exactly as they were for a failing commit before. - But ``T`` remains the current transaction object (if ``tm`` is ``T``'s transaction manger, ``tm.get()`` continues to return ``T``). - All subsequent attempts to do ``T.commit()``, ``T.join()``, or ``T.register()`` raise the new ``TransactionFailedError`` exception. Note that if you try to modify a persistent object, that object's resource manager (usually a ``Connection`` object) will attempt to ``join()`` the failed transaction, and ``TransactionFailedError`` will be raised right away. So after a transaction or subtransaction commit fails, that must be explicitly cleared now, either by invoking ``abort()`` on the transaction object, or by invoking ``begin()`` on its transaction manager. That's mostly what Victor reported, instances of: TransactionFailedError: An operation previously failed, with traceback: followed by the traceback of the _original_ exception that caused ZODB to mark the transaction as being fatally hosed. The original exception may have happened long in the past (but after the current transaction began). Each instance of such a thing points to one or two application bugs: 1. The original exception reported. and 2. That the original exception was suppressed to begin with (e.g, perhaps by a bare except: clause in the app, catching more than it really intended to catch), and without aborting the current transaction at the time in response. The originally suppressed exceptions in Victor's report: ValueError: Cache values may only be in one cache. and InvalidObjectReference: Attempt to store an object from a foreign database connection suggest that app code is sharing persistent objects across threads, e.g. loading an object O from one connection in thread A, and then in thread B trying to store a mutated O via B's connection. ZODB doesn't support that (it's fine if A and B have their own _copies_ of O, what they can't do is share an in-memory persistent object). The other exception reported is a sign that a module has been loaded into sys.modules more than once, under different dotted path names; while these can be nightmarish to untangle, they're not ZODB issues either: PicklingError: Can't pickle class 'Products.CMFNauTools.Explorer.FolderExplorer': it's not the same object as Products.CMFNauTools.Explorer.FolderExplorer ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] zodb connection question
[Jürgen Herrmann] ... so, what i need is a way to have my mechanism called before transaction commits (would be possible to use the hooks provided by zodb 3.4 for that, sure) and cycle through all modified objects (that's where the hooks in 3.4 are not enough for me, they don't provide any way to access a list of modified objects). Note that this isn't just a matter of exposing something to you: ZODB 3.4 has no list of modified objects, not even internally. Data managers (like ZODB.Connection) register with transactions in 3.3+, and data managers are responsible for keeping track of their own modified objects. Any number of data managers may register with a transaction, and each keeps track of its own details. So doing what you want would require at least two changes: 1. Adding a new method to the IDataManager interface, to deliver some notion of modified objects under the control of the data manager. Of course data managers would need to grow implementations of that too. Since you're presumably going to be changing even more objects based on the stream of modified objects returned, this can be tricky (do you get a point-in-time list, ignoring further changes? or an iterator that includes later changes? if the latter, is it OK to see an object more than once in the stream? like that). 2. Adding a related new method to ITransaction, to combine the notions of modified objects from all registered data managers. That's all doable, but it's hard to see it taking priority over other work. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Imagine if somebody tried to use ZPTs, and the answer to any question where you get errors from it is well, then don't use it? It's just not a viable answer. Refresh is not a core functionality like ZPT. That comparison is a bit outlandish. If it is the majoritys agreement that this answer is the best one, and that the refresh functionality should be looked at as something that may or may not work purely on luck, then I'll mark it as deprecated and up for removal in 2.10. +1 from me Maybe we can start looking at the last non-integrated version of the software, because it worked much better, and again make it a standalone product? Knock yourself out :) jens ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Try and fail connect strategy for zeo/zrpc
Sidnei da Silva wrote: | Does't the *already included* zeoup.py do exactly what you are trying | to do? See the bin directory of your zope home. Unfortunately no. It uses ClientStorage, which goes through the 1000's of lines of the connection dance using connect threads and large timeouts. Effectively, ClientStorage will retry a connection 'forever'. I just want to see if the port is listening and it smells like ZEO with the minimal reasonable timeout. Sounds like zeoup.py doesn't do what it should, which is what you're after. How about repairing zeoup.py rather than rolling yet another not-really-needed script? ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
On 7/12/05, Jens Vagelpohl [EMAIL PROTECTED] wrote: If it is the majoritys agreement that this answer is the best one, and that the refresh functionality should be looked at as something that may or may not work purely on luck, then I'll mark it as deprecated and up for removal in 2.10. +1 from me Maybe we can start looking at the last non-integrated version of the software, because it worked much better, and again make it a standalone product? Knock yourself out :) Marking stuff as deprecated is well within my competence, but actually making a working standalone product is probably not. :-) Ah well.. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
