Le mardi 20 mars 2012 13:06:16, Sebastian Wain a écrit :
It is a persistent queue with acknowledgment. The issue I see is the sync
of the BTree between threads. Consumers/Producers get/put elements, one at
a time, so before that operation can take place it will need to sync to
have the most
Le lundi 19 mars 2012 20:59:24, Sebastian Wain a écrit :
Indeed I want to sync the same BTree between threads. I am adding
persistence and acknowledgement to the Python queue.
I don't understand what you mean by:
- sync: ZODB is probably not a good backend to provide synchronisation as a
Le lundi 19 mars 2012 21:49:11, Jim Fulton a écrit :
sync should be deprecated. :)
transaction.begin() is better.
Off-topic: it is possible that calling transaction.begin() does not offer a
most up-to-date view of the database.
This is easy to notice when using another database concurrently
Indeed I want to sync the same BTree between threads. I am adding
persistence and acknowledgement to the Python queue.
I don't understand what you mean by:
- sync: ZODB is probably not a good backend to provide synchronisation as
a
feature, ie it's not a lock server and does what it can to
I am updating an item in a separated thread but when it finishes the new
value is not updated in the same object in the main thread.
In the example below root['counter'] starts in 0, is incremented in the new
thread but it remains in 0 in the main thread.
#!/usr/bin/python
from
I am updating an item in a separated thread but when it finishes the new
value is not updated in the same object in the main thread.
You need to call sync() on the connection object to see changes from
another thread.
http://zodb.readthedocs.org/en/latest/api.html#connections
In the example
Le lundi 19 mars 2012 18:57:53, Alan Runyan a écrit :
if your increment a counter its best the counter be of type, BTrees.Length
Depends on the usage. If generated numbers are intended to become unique
identifiers, a BTree.Length is definitely not what he wants.
Conflicts are good. In ZODB,
Le lundi 19 mars 2012 18:57:53, Alan Runyan a écrit :
if your increment a counter its best the counter be of type,
BTrees.Length
Depends on the usage. If generated numbers are intended to become unique
identifiers, a BTree.Length is definitely not what he wants.
Conflicts are good. In
On Mon, Mar 19, 2012 at 02:04:34PM -0300, Sebastian Wain wrote:
I am updating an item in a separated thread but when it finishes the new
value is not updated in the same object in the main thread.
In the example below root['counter'] starts in 0, is incremented in the new
thread but it
On Mon, Mar 19, 2012 at 4:36 PM, Marius Gedminas mar...@gedmin.as wrote:
On Mon, Mar 19, 2012 at 02:04:34PM -0300, Sebastian Wain wrote:
...
As Alan said, you need a connection.sync() here.
I believe calling transaction.begin() again at this point would also do
that (just remember that
10 matches
Mail list logo
