Boost logo

Boost :

Subject: Re: [boost] [transaction] New Boost.Transactionlibraryunderdiscussion
From: strasser_at_[hidden]
Date: 2010-01-21 14:48:54


Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>>
>> 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?
>
>
> 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.

ok, I see.
consider the following example:

transaction roottx;

//modify res1
//modify res2 (1)

{
   transaction nestedtx;
   //modify res1
   nestedtx.commit(); // (2)
}

rootrx.commit();

like we´ve said, res2 isn´t taking part in the nested transaction,
there is nothing between lines (1) and (2) that could create a
conflict in res2.

so if Boost.STM tries to discover conflicts as early as possible, why
wasn´t the conflict discovered in line (1)?

is Boost.STM checking for conflicts regularily, but not on every
access, so line (1) doesn´t check for conflicts but you want to check
for conflicts if the nestedtx takes, like, 10 seconds of runtime?

if that´s the case we could implement something in
basic_transaction_manager that regularily calls a resource manager so
it can check for conflicts e.g. once every second even if a resource
doesn´t take part in a transaction.

what exactly triggers that in Boost.STM at the moment?

I understand that this must be part of regular calls by the user and
cannot be part of another thread, because the exception must be thrown
in the user´s thread. but I don´t think that is a reason to drop the
lazy construction of resource transactions entirely.

take e.g. using Boost.STM and using a remote SQL database together,
both managed by Boost.Transaction.
starting a transaction to access boost.STM would automatically send a
BEGIN to a, possibly remote, SQL database, if resource transaction
aren´t lazily constructed, even though all you wanted to do is access
some transactional memory.

>> 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.

I think I know what you mean now, but are you really sure you prefer
that approach? I see several problems with it, IIUC.

example:

typedef basic_transaction_manager<my_mixin,...> txmgr;

struct my_mixin{
   txmgr &instance(){
     //construct transaction manager and accompanying resources,
     //using this->db_filename;
   }
   static char *db_filename;
   ...
};

int main(){
   my_mixin::db_filename="file.db";
   my_mixin::...=...;
   ...
   basic_transaction<txmgr> tx;
   ...
   tx.commit();
}

1. it´s strange code in my book. requiring the user to initialize
runtime configuration options before it is lazily constructed by a
call to instance() of basic_transaction.
2. the fact that it is lazily constructed requires the call to
instance() be protected by a mutex, or call_once. this is a global
mutex, spanning all threads, locked at each call to
basic_transaction_manager::active().

did I get that right? if this is not what you meant please provide a
code example.

Regards,

Stefan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk