Bug 700 - Which transaction to abort ?
Summary: Which transaction to abort ?
Status: ASSIGNED
Alias: None
Product: Ood
Classification: Unclassified
Component: Object Saving & Loading (show other bugs)
Version: 0.1
Hardware: PC Linux
: P1 normal
Assignee: Werner Van Belle
URL:
Depends on:
Blocks:
 
Reported: 2010-08-01 13:54 CEST by Werner Van Belle
Modified: 2010-08-01 13:54 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Werner Van Belle 2010-08-01 13:54:31 CEST
Comitting an update to something that was srtill locked by another transaction is problematic when that transaction no longer exists and will also no longer exist. So what do we do with this problem:

a- we can choose to abort any transaction linked to a client that died. This is a bad idea since it would mean that the transaction itself can never be a long lasting transaction. Also the connections are not supposed to be 'on' the full time. So aborting when client dies is not an option
b- we can choose to abort the transaction that already acquired the writelock ? Which would make it difficult to commit long transactions.

We could keep track of the damage caused by a specific transaction and kill the fucker if we feel like it. We could also keep track of the time a transaction has been doing nothing and throw the one out that did the least so far.