Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: strasser_at_[hidden]
Date: 2010-02-14 20:27:32

it obviously makes sense to keep the requirements on RMs/TMs as simple  
as possible, so sorry if I seem to attack every single one of your  
requirements. I only do this to make sure we don't introduce  
unnecessary requirements on every RM.

Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
> void rollback_only(); | void force_to_abort();

what's the difference between calling rollback() and calling rollback_only?
I guess rollback_only() doesn't rollback immediatly but only marks the  
transaction and doesn't let you commit afterwards. but what is the  
benefit of that? example?

what does commit() do after rollback_only() was called? throw?
can't you then call rollback() instead of rollback_only() and let  
commit() throw when the transaction is already rolled back?

> void restart();

we've discussed this shortly before, making RMs support restarting  
transactions is not trivial. it would mean that

unspecified begin_root_transaction();

is changed to

void begin_root_transaction(transaction &);

and "transaction" must be DefaultConstructible.

and every RM must support cleaning up a "transaction" object, possibly  
using a pointer to an internal transaction object or using  
boost::optional's internally to be able to re-construct it, if not all  
objects that are internally used can be cleared.

do you really think this is worth having the small performance gain  
you talked about, ONLY in the case of an isolation_exception?

if you need this for the purpose of the macro syntax only, you could  
wrap basic_transaction in a simple class like this:

struct restartable_transaction{
   void restart(){ tx=in_place(); }
   optional<basic_transaction> tx;
};

I'd really like to keep this out of the RM requirements.

>
> bool is_top_level();

what's top-level? root?

> transaction_state status();
> where
> enum transaction_state {
>     active,
>     marked_roolback_only, | forced_to_abort
>     prepared,
>     committed,
>     rolledback,
>     preparing,
>     committing,
>     rollingback
>     ...
> };
> or
> bool active();
> bool marked_roolback_only()
> bool prepared()
> bool commited();

some of the status here seem to be "unstable" to me, i.e. would never  
be in effect while the user has a chance to query it.
committing a transaction is a non-thread-safe operation (i.e., you  
can't commit in one thread and query the status of the transaction in  
another thread concurrently). so unless I'm missing something most of  
the listed status are never in effect when the caller has control.

e.g., when would prepared() return true?

what's left is: active, committed, rolledback, and possibly  
marked_rollback_only.