Re: [boost] Boost library submission (poll for interest)

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 https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction.
> 
> 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.

Best,
Vicente