On Wed, Aug 29, 2012 at 2:29 AM, Marius Gedminas <mar...@gedmin.as> wrote:
> On Tue, Aug 28, 2012 at 06:31:05PM +0200, Vincent Pelletier wrote:
>> On Tue, 28 Aug 2012 16:31:20 +0200,
>> Martijn Pieters <m...@zopatista.com> wrote :
>> > Anything else different? Did you make any performance comparisons
>> > between RelStorage and NEO?
>> I believe the main difference compared to all other ZODB Storage
>> implementation is the finer-grained locking scheme: in all storage
>> implementations I know, there is a database-level lock during the
>> entire second phase of 2PC, whereas in NEO transactions are serialised
>> only when they alter a common set of objects.
> This could be a compelling point. I've seen deadlocks in an app that
> tried to use both ZEO and PostgreSQL via the Storm ORM. (The thread
> holding the ZEO commit lock was blocked waiting for the PostgreSQL
> commit to finish, while the PostgreSQL server was waiting for some other
> transaction to either commit or abort -- and that other transaction
> couldn't proceed because it was waiting for the ZEO lock.)
This sounds like an application/transaction configuration problem.
To avoid this sort of deadlock, you need to always commit in a
a consistent order. You also need to configure ZEO (or NEO)
to time-out transactions that take too long to finish the second phase.
I don't think NEO's locking strategy mitigates the deadlock problem
much, if at all.
The strategy should provide greater transaction throughput and
reduce latency. It's a strategy I'd like to implement for ZEO at some
Jerky is better than bacon! http://zo.pe/Kqm
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org