[ZODB-Dev] Checking transaction status 2?

[ender]

accidently hit send before i was finished... 

On Tuesday 10 July 2001 13:59, Jim Fulton wrote:
>>
>>This is exactly right.  There are a couple of issues here:
>>
>>  - The transaction implementation needs to be replaceable,
>>    so that you can implement different transaction management
>>    policies. I'd like to see:

>>    o Transactions moved into a separate package (from ZODB)

this would be great.

>>    o Some attention given to making transactions more controllable.

i think there actually two issues here, transaction manipulation ie pluggable 
transaction managers, and pluggable transaction implementations.

one more thing i'd like to add to (which may have been implied) compatiblity 
with existing transaction semantics. 

>>  - There has to be a way for objects find the transaction manager
>>    globally. This seems to mean that there can only be one
>>    transaction per thread. Maybe there should be a version of
>>    get_transaction that lets you pass an argument (e.g. a connection)
>>    that that could contain data for deciding what transaction to return.
>>    Hm. This deserves some more thought.

ok i'm thinking out loud some brainstorming i did.

first some use cases that i'm using as a guide.

- an async connection from zope that utilizes transaction semantics. for 
connection to databases and other possible long time to response systems. 
some of this seems compatible with john's corba integration, but i'm not 
knowledgable enough of corba's calling semantics to say much. 

- single threaded multiple concurrent transaction applications. this seems 
compatible with christian's usage and with a single threaded asyncore system 
that utilizes only one connection. hmm... that brings up an interesting 
question, how does zope work in single threaded mode. i've never really 
figured that out, the medusa thread does not appear to be part of the 
publishing pool...

- multi-threaded zope, as it exists today.

i think transactions should be independent of both threads and connections, 
but maintain compatibilty with existing thread centric approach. indepedence 
of connections to me goes along with both a pluggable transaction 
implementation and with separation from the zodb.

as for accessors, i'm slightly against loading up get_transaction with a host 
of conditional operators. it makes for a loss of clarity and possible abuse 
of the intention of that name, although this is dependent on implementation 
strategy. systems which need more explicit transaction control than whats 
offered should access the module singleton/functions of Transaction


ok sketching out my idea for an implementation strategy in a some classes

TransactionIdGenerator -  generate unique transaction ids. for concurrent 
transactions in the same connection this seems key. to avoid excessive 
locking this could be based on a time.time() or random number generator, 
although i'm unsure of possible complications that might arise from zeo 
integration and clock skew for a time approach.

TransactionThreadMapping - associate transaction id with a thread. this is 
mainly for compatibility withe existing semantics of 1 thread/ 1 transaction. 
its interesting here that locking is probably unescessary if certain 
assumptions hold true. namely that the only manipulator of this structure 
would be a thread changing its own tid value.

TransactionMap - associate transaction id with a transaction object

and then some accessor functions.

leaving get_transaction untouched except for an optional transaction_id arg, 
and to update above structures if a new transaction is created as a result.

the below might be better implemented by extending the transaction object as 
john did. 

adding a set_transaction(transaction_object) to set the transaction 
association with the current thread.

adding a new_transaction function to get a transaction unassociated with a 
thread.

adding a remove_transaction() to detach the transaction associated with the 
thread.


hmm... does this seem reasonable?

-waiting-patiently-for-brighter-heads-and-remembering-ipc9-ly yours

kapil