Boost logo

Boost :

Subject: Re: [boost] Boost library submission (poll for interest)
From: strasser_at_[hidden]
Date: 2010-01-17 16:30:23

Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:

>> Yes. Stefan had suggested this in private e-mails earlier, and I'll
>> have to adapt to fit his interfaces.
>> As I've alluded previously, I would like to see it possible to
>> use Boost.Persistence with my library, as several shortcomings of
>> STLdb would be addressed in that way. Part of doing that involved
>> bringing all transaction control under one manager. Stefans library
>> is the most robust in this sense, so I plan to work with and adapt to
>> his interfaces.
> I have proposed in a private mail to split its library in two
> Boost.Transaction and Boost.Persistency. I think this is the right
> direction.

before I do that, I would like to have a thorough discussion of the
design decisions I made, especially the first one of the list, because
it deeply affects the way your libraries would have to be set up.


every transactional entity like a trans_map or a shared_loc must be
aware of the static type of the transaction manager, which can change
by user configuration.

this results from the following:

every access to a transactional entity without explicit "transaction"
argument must go through the transaction manager
==> calls through transaction manager must be efficient
==> there can be no dynamic polymorphism
==> the static type of the transaction manager changes by
configuration(a transaction manager using Boost.Persistent has another
type than one that uses STLdb, which has another type than a
transaction manager using both libraries)
==> all transactional entities must be aware of the static type of the
transaction manager.

so in my library every transactional entity is a template with the
type of the transaction manager as parameter:


and so on.
for convenience of the user that only uses one type of transaction
manager, there are aliases defined:

transaction, alias for basic_transaction<transaction_manager>,
shared_loc<T>, alias for basic_shared_loc<T,transaction_manager>

transaction_manager is a typedef that currently is by default a
transaction manager that uses Boost.Persistent, but can be changed by
defining BOOST_PERSISTENT_CONFIGURATION before including the aliases.

there are several obstacles with this approach:
  - every type that ought to be used with a configurable transaction
manager must be a template.
  - C++98 has no template aliases.
in C++0x shared_loc could be a simple alias of basic_shared_loc:

template<class T>
using shared_loc = basic_loc<T,transaction_manager>;

in C++98 however a class "shared_loc" that acts like an alias for
"basic_shared_loc" has to be implemented.

this would have to be done for every class like that of your libraries, too.

do your libraries allow access by multiple threads to the SAME transaction?
because this requires a mutex lock in the transaction manager for each
access, which might be a performance concern?
if your libraries only allow one thread to use a transaction, this
mutex lock can be removed by changing a template argument of

pseudo-code of the function of basic_transaction_manager that returns
the resource transaction:

global_transaction &tx;
return tx.resource_transaction();

transactions are bound to the current thread when they are created,
but transaction managers are bound to the whole application.

my_transaction_manager t1;
my_transaction_manager t2;

//t2 is the current transaction manager, even when another thread is
started. bind() can be used to bind another transaction manager for
all running threads.

creating and binding of transaction managers is not thread-safe.

please have a look at the following parts of the documentation:

TransactionManager concept:

ResourceManager concept:

Boost list run by bdawes at, gregod at, cpdaniel at, john at