SV: [ZODB-Dev] get_transaction

[Greg Ward]

On 30 November 2001, Magnus Heino said:
> I found a simular question in
> http://lists.zope.org/pipermail/zodb-dev/2000-September/000447.html too,
> that never got an answer, I'll do some cut'n'paste;

[Magnus quotes me from a year ago:]
[...]
> Cool!  I think this is (part of) the behaviour I was looking for -- same
> database object, different in-memory "facade" presented to the Python
> code working on it.
> 
> The clue I'm missing is how to "unify" the two disparate versions: how
> do I commit the changes to me1 so that me2 also becomes "Sir Greg Ward",
> or alternately, how do I abort the changes to me1 so that this change is
> never seen?

[Magnus again]
> So, is this possible?

I've learned a bit about ZODB in the last year, but I still don't really
understand it.  ;-(  I think I can answer part of my own question as
follows:

  * if you have two separate connections in different threads or
    processes, they're independent; you commit/abort changes on
    a connection with get_transaction().{commit,abort}(), and
    you can sync a connection with the current state of the
    database with connection.sync()

  * if you have two connections in the same thread, you can't
    do it -- as Chris and Jim responded

> Since I did my first post however, I changed my app quite a bit. I took the
> StandaloneZODB distro, ZServer and ZPublisher and put them together, in a
> way I took zope and changed it to publish my own modules instead. This way
> it handles transactions for me, just like zope does. But, the objects that
> I'm publishing are running threads that are changing the objects too.

You said the magic word: thread.  Each thread has a separate transaction
object, so you should be OK.  This is a dark, scary, and largely
undocumented corner of ZODB, so be careful!

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org