Bob Walters-2 wrote:
On Wed, Jan 13, 2010 at 7:49 PM, Brian Ravnsgaard Riis <brian@ravnsgaard.net> wrote:
One thing that immediately jumped at me, though, is this construct:
Transaction *txn = db.beginTransaction(); { ... } db.commit(txn);
From an exception safety POV: What happens if db.commit(txn) is never called here? The raw Transaction pointer raises my hackles immediately. Blame it on Stroustrup and Meyers! :-) Am I missing something here?
No. I should have at least used an auto there to ensure destruction. Actually the whole convention of the "database as factory" for transactions is something I'm going to rework so that you can have the transaction on the stack if you so choose. I do think I want to continue to support explicit transactions, but am very tempted by something Stefan is doing in Boost.Persistent, in which transaction scope is retained in thread-specific memory (I assume) and passed around implicitly. Support for that as an optional approach is something I need to do for those who prefer that.
Hi, if you can store the transaction on the stack you could use the atomic language-like macros Stefan provides in it Persistent library. I agree that you should support transparent as well as explicit transactions. transparent transaction have a cost to access the thread specific pointer. Best, Vicente -- View this message in context: http://old.nabble.com/Boost-library-submission-%28poll-for-interest%29-tp270... Sent from the Boost - Dev mailing list archive at Nabble.com.