Boost logo

Boost :

Subject: Re: [boost] Boost library submission (poll for interest)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-01-17 15:22:40

----- Original Message -----
From: "Bob Walters" <bob.s.walters_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, January 17, 2010 7:24 PM
Subject: Re: [boost] Boost library submission (poll for interest)

> Sorry for the delay here. Original reply bounced due to 'reply to
> digest' subject line.
> On Tue, 5 Jan 2010 21:21:29 +0100, "vicente.botet"
> <vicente.botet_at_[hidden]> wrote:
>> I'm interested on a library that has transactional shared memory, but something more general that your containers database in shared memory. Can your library be extendeed to manage with types that are not containers?
> Currently there is an interface between the trans infrastructure (TI)
> and the containers allowing the containers to offer transactional
> operations, and indicate to the TI how they should be logged,
> committed, etc. This was intended to help make adding containers
> easier. There isn't really an assumption that transactional objects
> are containers - they could be anything which adheres to the
> interface. For example: I'm planning a quick wrapper for types T
> which makes T transactional for updates done to it via operator=. I
> need this for integerss that I want to use as
> sequences in one use of STLdb. (e.g. for key generation.)
>> If I have understood, the data is stored using Boost.Interprocess. Could you clarify why do you force the stored types to be Serializable?
> I'm not relying on the durability of the boost interprocess region.

Why? What are the main problems with this approach?

> Nor am I trying to serialize the shared memory from directly to disk.
> Stefan has challenged me to do that, and I'm considering a variation
> which would do that, but it isn't without it's own issues.

Could you develop?

> For now, I
> went with the approach of using serialization for sending K,V types to
> logs or checkpoints as a way to avoid those issues.
> My current concern with direct storage is that (assuming K and V may not
> be concrete types) it seems like it will require a lot of memory use
> tracking which could add an unwanted expense to shared memory pointer traversal.

I don't understand what K and V are? (Key, Value?)

>> With your library, there are alreasy 3 libraries under construction providing a transactional service (Boost.STLdb, Boost.Persistent and TBoost.STM). The ideal would be to have a single transactional framework with several transactional resources, e.g shared memory resource (Boost.STLdb), persistent resource (Boost.Persistent ), in memory resource (Boost.STM). If I'm not wrong Boost.Persistent contains already a Ressource concept. I would like to see how this transactional framework can be made generic so the three libraries can share the same transaction. Stefan, Bob, are you interesteed in participating on such a framework?
> 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.

>> Could you give a link from where to download the code. If you want I can add your library to the Boost Libraries Under Construction page
> Currently it's in subversion only on sourceforge. I'm finishing
> some changes to the checkpointing mechanism, and I'm going
> to finish that first. Will let you know when its ready, thereby
> supporting the under construction entry. If it helps at all, I could
> move the SVN repository to the sandbox, or post the tarball into the Vault (?)

The address of the repository should be OK for the moment.


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