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..
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
