When should one call Connection.sync?
I am using ZODB 3.2 in a twisted based web application. I have read that I need to call sync to keep the connection up to date. When exactly should I call sync? Are there any drawbacks with calling it immediately after getting a connection, like this: # for each http request. connection = db.open() # (a DB instance) connection.setLocalTransaction() connection.sync() # start using the ZODB here. # if something needs to be committed connection.getTransaction().commit()
Syver Enstad <syver@inout.no> writes:
I am using ZODB 3.2 in a twisted based web application. I have read that I need to call sync to keep the connection up to date. When exactly should I call sync? Are there any drawbacks with calling it immediately after getting a connection, like this:
# for each http request. connection = db.open() # (a DB instance) connection.setLocalTransaction() connection.sync()
# start using the ZODB here.
# if something needs to be committed connection.getTransaction().commit()
I have done some experiments with this scheme and I find that everything gets unloaded when do a connection.close() or connection.sync() so that performance takes quite a hit.
Syver Enstad wrote at 2004-4-21 18:03 +0200:
Syver Enstad <syver@inout.no> writes:
I am using ZODB 3.2 in a twisted based web application. I have read that I need to call sync to keep the connection up to date. When exactly should I call sync? Are there any drawbacks with calling it immediately after getting a connection, like this:
# for each http request. connection = db.open() # (a DB instance) connection.setLocalTransaction() connection.sync()
# start using the ZODB here.
# if something needs to be committed connection.getTransaction().commit()
I have done some experiments with this scheme and I find that everything gets unloaded when do a connection.close() or connection.sync() so that performance takes quite a hit.
Maybe, the connection cache is too small. Usually, an incremental cache garbage collection is performed in "connection.close()" and at transaction boundaries ("sync" causes an implicit "transaction.abort()" which means, it marks a transaction boundary). The cache garbage collection tries to flush as many objects from the cache as are necessary to reach the target cache size. -- Dieter
Dieter Maurer <dieter@handshake.de> writes:
Syver Enstad wrote at 2004-4-21 18:03 +0200:
I have done some experiments with this scheme and I find that everything gets unloaded when do a connection.close() or connection.sync() so that performance takes quite a hit.
Maybe, the connection cache is too small.
Usually, an incremental cache garbage collection is performed in "connection.close()" and at transaction boundaries ("sync" causes an implicit "transaction.abort()" which means, it marks a transaction boundary). The cache garbage collection tries to flush as many objects from the cache as are necessary to reach the target cache size.
Yes that was the problem, I found out about this after some experiments and by upping the cache_size to at least 20 000 I manage to keep the instances in memory even when I do a sync or close. Thank you anyway.
participants (2)
-
Dieter Maurer -
Syver Enstad