On Sun, Jan 12, 2014 at 07:46:13PM -0500, Michael Bayer wrote:
On Jan 11, 2014, at 9:42 PM, Laurence Rowe laurencer...@gmail.com wrote:
2. Make the engine Transaction aware of the configured reset_on_return
behaviour so that Transaction.close() can either rollback or commit.
On Jan 11, 2014, at 9:42 PM, Laurence Rowe laurencer...@gmail.com wrote:
The tpc state (xid, is_prepared) is held on the TwoPhaseTransaction object,
referenced (self.__transaction) by the engine Connection object which calls
conn.close(). I don't think SessionTransaction need be involved
On Friday, 10 January 2014 08:06:16 UTC-8, Michael Bayer wrote:
maybe. I was thinking, is the Session really doing the right thing here
by not getting involved, but I think yeah that still might be appropriate.
so we’d need to carry along some extra information about the transaction
On Thursday, 9 January 2014 09:41:40 UTC-8, Jeff Dairiki wrote:
Okay, I've traced things out a bit more.
If the session state is not STATUS_INVALIDATED (aka STATUS_CHANGED),
SessionDataManager.commit() does a self._finish('no work'). That is
where self.tx gets set to None (this ---
On Jan 10, 2014, at 3:32 AM, Laurence Rowe laurencer...@gmail.com wrote:
On Thursday, 9 January 2014 09:41:40 UTC-8, Jeff Dairiki wrote:
Okay, I've traced things out a bit more.
If the session state is not STATUS_INVALIDATED (aka STATUS_CHANGED),
SessionDataManager.commit() does a
Thank you for the reply! Sorry for the delayed response. (Holidays.)
On Mon, Dec 23, 2013 at 11:52:25PM -0800, Laurence Rowe wrote:
On Thursday, 12 December 2013 16:30:59 UTC-8, Jeff Dairiki wrote:
Do you understand why the datamanager is finding the SessionTransaction
and using that
On Thursday, 12 December 2013 15:26:08 UTC-8, Thierry Florac wrote:
Hi,
I'm using two-phase transactions with ZODB, PostgreSQL and Oracle
databases connected with SQLAlchemy without problem.
I'm not using native zope.sqlalchemy package, but another package called
ztfy.alchemy that I've
On Thursday, 12 December 2013 16:30:59 UTC-8, Jeff Dairiki wrote:
Do you understand why the datamanager is finding the SessionTransaction
and using that directly? (At least I think that's what it's doing ---
I haven't sussed this out completely.) I'm referring to the line from
On Saturday, December 14, 2013 9:58:14 PM UTC-5, Jeff Dairiki wrote:
Oh my god. I'm just going to close that page, and try to forget I
ever saw that... On quick look though, none of those modes seem to
have anything to do with transactions (thankfully).
Yeah, it's pretty evil. I've
Thanks for the replies!
On Fri, Dec 13, 2013 at 08:40:33AM -0800, Jonathan Vanasco wrote:
Also, I'm remembering the stuff about the need to use 'mark_changed'. on
the project page ( https://pypi.python.org/pypi/zope.sqlalchemy ) search
for the section about `mark_changed` -- that info might
On Sat, Dec 14, 2013 at 06:58:14PM -0800, Jeff Dairiki wrote:
Thanks for the replies!
On Fri, Dec 13, 2013 at 08:40:33AM -0800, Jonathan Vanasco wrote:
Also, I'm remembering the stuff about the need to use 'mark_changed'. on
the project page ( https://pypi.python.org/pypi/zope.sqlalchemy
just a thought--
two things:
1- The thing is, for me, if the session has only been used for read
operation,
self.tx seems to be None. So the datamanager never commits anything.
Check out Tres Seaver's reply
here: https://groups.google.com/d/msg/pylons-discuss/R4S-UwHV6ww/ekD7M9UEvp8J
Hi,
I'm using two-phase transactions with ZODB, PostgreSQL and Oracle databases
connected with SQLAlchemy without problem.
I'm not using native zope.sqlalchemy package, but another package called
ztfy.alchemy that I've built (based on zc.alchemy and zope.sqlalchemy), and
I didn't tried with MySQL.
On Fri, Dec 13, 2013 at 12:26:08AM +0100, Thierry Florac wrote:
Hi,
I'm using two-phase transactions with ZODB, PostgreSQL and Oracle databases
connected with SQLAlchemy without problem.
I'm not using native zope.sqlalchemy package, but another package called
ztfy.alchemy that I've built
I just noticed my connection pool isn't pooling. Whenever a connection
which has been used only for reading is returned to the pool an
XAER_RMFAIL operational error is returned in response to the pools
rollback-on-return. (This causes the connection to
be closed rather than returned to the pool.
15 matches
Mail list logo
