[Zope-dev] Making a ZSQL.DA fully multi-threaded?

[sathya]

I dont see a data loss problem either (unless there are hardware failures)

If a connection is dropped due to inactivity it  should not affect any
transactions going to occur in the future as a reconnect is issued
before submitted new transactions.

However connections getting dropped due to transport layer problems is a
different matter.
if a connection gets dropped by either side after making the request
then it should be detected at either end and the transaction aborted
(assuming
a well behaved transport layer). There cannot be any loss in data in
this scenario. This is expected behaviour with any RDBMS connection
infrastructure, i.e If  the transport layer guarantees delivery and
employs the customary  process of error detection and informs the
application there should not be  a  data inconsistency problem ( unless
there is a hardware failure )

I beleive Whether or NOT the transaction is resubmitted should be  a
decision on part of the application and not the DA or Zpublisher. The
application can make a decision based on the circumstance and then if it
chooses to do so issue the conflict error to invoke  the Zpublisher
machinery.


Brad Clements wrote:

>On 23 Jul 2004 at 20:08, Dieter Maurer wrote:
>
>  
>
>>The bad sequence can look as follows:
>>
>> * Zope starts a request (and thereby a transaction)
>>
>> * The request sends a modifying request to a relational database
>>
>> * The connection is lost; the former modification is discarded
>>   as the database performs an automatic abort on connection close
>>    
>>
>
>The former modification cannot be lost because it was commited by the DA as part of the 
>previous transaction.
>
>At least, gvibDA performs a database commit as part of the overall transaction machinery.
>
>So again, I don't see the loss..
>
>
>  
>