Re: conn.close() idempotence

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/
_______________________________________________
DB-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/db-sig