I'm developing a Plone module with sqlalchemy 0.7.3 and postgresql
9.1. I'm making use of postgres' new 'True Serializiation' feature to
ensure that concurrent writes do not lead to conflicts.

Since true serialization is quite expensive I started to use two
connections for each server thread:
 - One with isolation_level set to serialization.
 - One with the default read committed.

The serialized session is used for writes, the other is used for
reads.

I use sqlalchemy together with zope.sqlalchemy which handles the
commits. If anything at all goes wrong during the server request the
sessions are rolled back.

For that reason I never really have access to committed data during a
request, unless I only use the serialized connection.

This is the simplified setup:


    zope.sqlalchemy -> begin
        serialized_session.begin()
        serialized_session.add(something)
        serialized_session.flush()
        read_session.query(something) <- returns nothing
    zope.sqlalchemy -> commit / rollback


Of course this is to be expected, as these two sessions do not share
the connection nor the state (though they are in the same thread).


My question is this:


Is there any way for me to share the pending objects of the serialized
session with the read session? I would like to ensure that the read
session used in the same request as the serialized session sees the
same data.


I can't simply commit the serialized session myself, because I do want
zope.sqlalchemy to ensure that everything is rolled back if there's
any exception during the request.

And I also have to avoid reading from the serialized session as much
as possible because it increases the change of postgres blocking.

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to