My error was about self.db attribute in
'_v_database_connection' not about '_v_database_connection'
attribute itself. During abort() of this resource manager
self.db was None so self.db.rollback() failed. I'll check
this again...
I've messed up things. Error that I've found is in
StoredProcedur
How can I get access to this?
The value of the "_v_" attribute is *the* resource manager
registered with the transaction.
Ups... of course! I've made mistake - sorry.
My error was about self.db attribute in
'_v_database_connection' not about '_v_database_connection'
attribute itself. Du
Maciej Wisniowski wrote at 2006-9-28 23:05 +0200:
> ...
>I don't know how abort of ZODB resource managers works but
>doesn't rollback of ZODB resource manager remove _v_ variables?
Usually not.
An abort only deactivates (and deactivation kills the "_v_" variables
together with other content) thos
If these conditions are met, you will lose your connection. Still
nothing bad happens as the transaction still holds a reference to it
and may eventually commit/abort it at transaction end time.
(...)
And as they are very rare and apparently non-deterministic,
they are almost impossible to
If one is careful, one can find a reliable solution...
Hopefully I think I did this today...
I've found that psycopg pool implementation has nice
class:
class PersistentConnectionPool(AbstractConnectionPool):
"""A pool that assigns persistent connections to different threads.
Note tha
Maciej Wisniowski wrote at 2006-9-27 22:40 +0200:
> ...
>> It can lead to nasty, apparently non-deterministic effects.
>> You may lose your database connection mid transaction
>> and part of what you think is a transaction (i.e. atomical) can be lost.
>>
>>
>What are the circumstances under
Maciej Wisniowski wrote at 2006-9-27 21:38 +0200:
> ...
>To be able to finish whole transaction
>for the relational DB...
No.
There are two reasons:
1. that later operations see the effects of earlier
operations in the same request
and more importantly
2. to avoid deadlocks.
It can lead to nasty, apparently non-deterministic effects.
You may lose your database connection mid transaction
and part of what you think is a transaction (i.e. atomical) can be lost.
What are the circumstances under which this can occur? I've found something
similiar (?) when I wa
Pool based connections can be tricky as well:
When a DA instance is accessed several times during the
same request, it *MUST* use the same connection.
To be able to finish whole transaction
for the relational DB...
I know that the "ZPsycopgDA" which comes with "psycopg 1.x" uses
"_v_"
Maciej Wisniowski wrote at 2006-9-27 17:49 +0200:
> ...
>Thanks again for explanations. Seems that I'll change my DA's
>(DCOracle2 and ZCxOracleDA) to use connection pool like psycopg
>does. After quick look at their (psycopg) solution I think it is really good
>and solves (or may solve) few other
Not strictly speaking in ZODB:
The "_v_" use for database connections is dangerous (and if you
want buggy).
It can lead to nasty, apparently non-deterministic effects.
You may lose your database connection mid transaction
and part of what you think is a transaction (i.e. atomical) ca
Maciej Wisniowski wrote at 2006-9-25 20:09 +0200:
>
>>It uses a private ZODB extension to prevent "_v_" attributes to be lost
>>mid transaction (which can have nasty, partly non deterministic and
>>very difficult to understand effects) and then calls "connect".
>>
>>
>Does this mean that there is
It uses a private ZODB extension to prevent "_v_" attributes to be lost
mid transaction (which can have nasty, partly non deterministic and
very difficult to understand effects) and then calls "connect".
Does this mean that there is a bug in ZODB?
Thanks for your explanations. I've override
Dieter Maurer wrote:
However, it really is now as you describe it...
Well, you should be a foundation member by now, right?
Yes,
Yay!
but my SVN access is not yet working (probably due to a '.' in
my Zope user account).
Could you not just register another account name at zope.org and us
Maciej Wisniowski wrote at 2006-9-24 22:00 +0200:
> ...
>Do you have 'connect_' defined elsewhere or it is expected to raise
>an exception here and just log this?
Sure, I have defined "connect_".
It uses a private ZODB extension to prevent "_v_" attributes to be lost
mid transaction (which can ha
ZODB. My modified code looks like:
def __setstate__(self, state):
Globals.Persistent.__setstate__(self, state)
if self.connection_string:
# DM 2005-06-24: what a stupidity to connect on load!
# It should be delayed until the connections is really used.
Maciej Wisniowski wrote at 2006-9-23 00:27 +0200:
> > You could recode DA's to close the connection at the end of every
> > transaction and reopen them on demand,
>Seems for me that difference betwen "connect on load"
>and "connect on demand" is in _begin, _finish and
>__init__ methods of Transacti
> You could recode DA's to close the connection at the end of every
> transaction and reopen them on demand,
Seems for me that difference betwen "connect on load"
and "connect on demand" is in _begin, _finish and
__init__ methods of TransactionManager (usually defined in db.py
in specific database
Chris Withers wrote at 2006-9-22 10:48 +0100:
>Dieter Maurer wrote:
>> M.-A. Lemburg wrote at 2006-9-20 23:00 +0200:
>>> ...
>>> I'll correct that slightly: Zope DAs usually open the connection
>>> as soon as the connection object is loaded into memory, e.g.
>>> if you look at the folder contents c
Dieter Maurer wrote:
M.-A. Lemburg wrote at 2006-9-20 23:00 +0200:
...
I'll correct that slightly: Zope DAs usually open the connection
as soon as the connection object is loaded into memory, e.g.
if you look at the folder contents containing the connection
object.
In my view, this is a bug in
M.-A. Lemburg wrote at 2006-9-20 23:00 +0200:
> ...
>I'll correct that slightly: Zope DAs usually open the connection
>as soon as the connection object is loaded into memory, e.g.
>if you look at the folder contents containing the connection
>object.
In my view, this is a bug in Zope's DA code.
H
Matthew T. Kromer wrote:
> Basically, no.
>
> You could recode DA's to close the connection at the end of every
> transaction and reopen them on demand, but to the best of my knowledge
> none of the DAs work that way.
>
> Once a connection object opens its connection it stays open but in the
> ob
Basically, no.
You could recode DA's to close the connection at the end of every
transaction and reopen them on demand, but to the best of my
knowledge none of the DAs work that way.
Once a connection object opens its connection it stays open but in
the object cache of that thread. This
Greetings. I'm having a problem with database connectors, and maybe you can give me a hand.
Is there a way to manage the opening and closing of database
connectors, apart from doing it from the zope management interface?
By this I mean, I want to implement a Python script that checks wether
a dat
24 matches
Mail list logo
