Re: [boost] [transaction] New Boost.Transactionlibraryunderdiscussion

Subject: Re: [boost] [transaction] New Boost.Transactionlibraryunderdiscussion
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-01-21 04:15:09

----- Original Message ----- 
From: "Stefan Strasser" <strasser_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, January 21, 2010 3:55 AM
Subject: Re: [boost] [transaction] New Boost.Transactionlibraryunderdiscussion

> 
> Am Thursday 21 January 2010 00:49:25 schrieb vicente.botet:
>> >> solves. How can you ensure that each resource has an equivalent stack of
>> >> local nested transactions if you create them only when the application
>> >> access a resource on the context of a global transaction?
>> >
>> I've seen that call. This ensure that you have a complete stack on the
>> moment of the resource_transaction, but not when the application commit.
>> This means that you can have resources that can participate on the
>> transaction on the  outer levels but not on the inner ones. As this
>> resource will not be commited when the inner transaction is commited, we
>> are unable to see conflicts with other transactions respect to this
>> resource.
> 
> what conflict can the other resource cause if there is no nested transaction 
> in it?
> 
> global_root_tx( resource1_root_tx, resource2_root_tx)
>        ^                  ^
>         |                   |
>         |                   |
> global_nested_tx(resource1_nested_tx, none)
> 
> global_nested_tx.commit():
> resource1_nested_tx is published into resource1_root_tx. how can this call 
> cause a conflict in resource2?

I said 
>>As this
>> resource will not be commited when the inner transaction is commited, we
>> are unable to see conflicts with other transactions respect to this
>> resource.

What I want is the the commit on  global_nested_tx see if this transaction must be aborted due the resource2 has conflics with other resources2 of transactions. No need to continue commiting N nesting levels on resorce1 if resource2 has already conflicts. This is maybe an optimization, but we use things like that in Boost.STM.

>> > how do you construct a transaction manager (and the resource managers
>> > used by it) at the point of (lazy) singleton construction if you don't
>> > have any constructor arguments?
>>
>> The answer was already in my preceding post. If basic_transaction_manager
>> is not able to define this function, we can make basic_transaction_manager
>> a mixin, that will have the final transaction_manager as parameter. Note
>> the new parameter Final.
>>
>> template<class Final, class Resources,bool Threads=true,bool TThreads=true>
>> class basic_transaction_manager {
>>     static Final& instance() { return Final::instance(); }
>>     ...
>> }
> 
> I don't understand what difference that makes. I thought your point was that 
> the transaction manager should be stored as an invariant singleton.
> How is that possible, with or without mixin? What does the mixim accomplish? 
> What is the difference between instance() and the current active()?

The trick is that instance is implemented by the Final class, and so can call a specific construtor. 
Your active() function is implemented by basic_transaction_manager, which is not able to make differences.
basic_transaction_manager instance function could in addition ensure that there is a single instance, but doesn't build it.

Best,
Vicente