Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
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. 1. 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: basic_transaction<TxMgr> basic_shared_loc<T,TxMgr> basic_loc_multiset<T,TxMgr,...> 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. 2. 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 basic_transaction_manager. pseudo-code of the function of basic_transaction_manager that returns the resource transaction: global_transaction &tx; lock_mutex(); if(!tx.resource_transaction_exists()){ tx.create_resource_transaction(); } return tx.resource_transaction(); 3. 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. 4. please have a look at the following parts of the documentation: https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/... TransactionManager concept: https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/... ResourceManager concept: https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/...