Am Sunday 23 August 2009 14:54:23 schrieb vicente.botet:
in the documentation you say,
"Objects can be read outside of transactions, but no object can be created or changed outside of transactions. "
So how do you manage with conflicts between reads outside transactions and writes inside transactions? Maybe you can clarify this on the documentation.
ok. a read outside of a transaction returns the committed state of that object at the time. (consistent state within the object.) if you need an atomic read across more than one object, you can use a transaction.
As db_ptr is a shared_ptr why not name it shared_db_ptr (note that you have already a weak_db_ptr) or even better, why don't name them shared_ptr and weak_ptr but on the namespace db?
db_ptr is not a shared_ptr, think of it more like an "object id". it does not keep the referenced object in memory, see pitfalls -> object lifetime for that. the name "db_ptr" is certainly imperfect and might depend on if the whole library stays with its name (robert ramey suggested a name change). the namespace currently is persistence.
Do you think that it will be possible to manage db pointers that are not managed, so it will be up to the user to create/remove them explicitly?
I'm not sure if I understand that question correctly...do you mean objects that are not reference counted and must be added and removed explicitely?
About commit_transaction, in TBoost.STM we have defined a macro atomic so you can do the following
atomic(_) { book->friends.push_back(...); }
thanks, I did look at it. how is the catch-block added? do you have to use another define after {}? though you could stop commit() from throwing and just let it return false to indicate that the transaction failed and avoid a catch block. I need to think that through though because not only commit() can throw isolation_exception, it can be thrown much earlier. but your macros still have a "try" at the end, I wonder what that's for?
Related to "Improving performance", what hapens if in a transaction we access a db_ptr using the read function, then we modify it in a neested function/transaction and then we re-read this shared_ptr. Will the readen pointer corresponds to the written one?
no. that is addressed in the documentation in pitfalls->transaction boundaries. maybe one could describe that more clearly and prominently in the final documentation. so objects should always be accessed through their db_ptr's. thanks for your comments. which version of the db_ptr interface do you prefer? (at the end of overview.html)