[DB-SIG] conn.close() idempotence
M.-A. Lemburg
mal at egenix.com
Wed Oct 19 10:49:14 CEST 2011
Thinking about this some more ...
Perhaps what you're really after is the following and I was just
misunderstanding the original proposal:
class Connection:
closed = False
def close(self):
if self.closed:
return
# close the connection
...
self.closed = True
In other words, you don't silence any errors, but instead use
a flag to store the successful close operation and then simply
ignore all future calls to the method without raising an
exception.
M.-A. Lemburg wrote:
> Federico Di Gregorio wrote:
>> On 19/10/11 09:59, M.-A. Lemburg wrote:
>> [snip]
>>>> risks to become a problem, with the close() that may raise an error
>>>>> because the connection has been implicitly closed by a communication
>>>>> error. Note that close() in itself often is a quite safe operation,
>>>>> not involving database communication, so it is not expected to fail
>>>>> and may not be well guarded.
>>> That last sentence is not quite correct: .close() issues an implicit
>>> .rollback() and usually also tells the database backend to free up
>>> resources maintained for the connection, so it does require communication
>>> with the backend.
>>
>> Here is the problem. Does .close() always issue an implicit .rollback()?
>
> Yes.
>
>> The DBAPI says yes but, as noted previously, the driver can choose to
>> NOT send a rollback.
>
> Not if it complies to the DB-API.
>
>> In fact on the second .close() the driver SHOULD
>> NOT send a rollback because there is no transaction in progress.
>
> The second .close() would in that case raise an exception
> as per the definition in the database, since it has become
> unusable :-)
>
> BTW: Regardless of whether the driver explicitly issues a rollback
> or not, the database backend will roll back the connection if the
> connection closes and there's a pending transaction.
>
>> I'd vote for idempotent .close() interpretation too.
>
> Please read my full reply: the implicit rollback is not
> the only operation that can fail. Silencing errors is not
> a good idea.
>
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 19 2011)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
More information about the DB-SIG
mailing list