incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Transactional TDB
Date Tue, 01 Nov 2011 11:10:44 GMT
On 31/10/11 16:25, Laurent Pellegrino wrote:
> Thanks Andy for these information.
> Regarding the Location.mem() method I have noticed that it does not
> create internally a new "mem location object" each time the method is
> called. Thus, if I create several instances of StoreConnection in a
> JVM by using Location.mem() as parameter, all the StoreConnections
> will share the same location. Is it not possible to create a unique
> memory location each a call to Location.mem() is performed? This would
> be very useful to reproduce what is possible with new
> Location("/unique/path/").
> Kind Regards,
> Laurent

Currently, StoreConnection.make manages a cache based on location so 
that the application gets the same StoreConnection (like JDBC, e.g. in a 
web app asking for a connection).

The constructor for StoreConnection is private to force everythign to go 
via the cache.

in-memory is a bit different - it's resaonable to want several separate 
ones, and ideally Location.mem would itself take a name to identify 
different Locations areas backed by RAM.

Adding a non-caching StoreConnection.createMem() is also doable.

So I understand the use case, why do you want separate in-memory databases?

> On Sun, Oct 30, 2011 at 6:05 PM, Andy Seaborne<>  wrote:
>> On 29/10/11 15:06, Laurent Pellegrino wrote:
>>> Hi all,
>>> I have several questions about how to use the new transaction features
>>> provided with the last version of TDB:
>>> * Do we have to use the commit operation with a read transaction? Is
>>> it compulsory (e.g. to release a lock), optional, or an error?
>> If you are using transaction at all, then you must use a read tranaction (it
>> can end with commit, abort or close - it'll make no difference for read).
>> Locking is not needed except that each transaction must be single threaded
>> (basically, multiple-reader OR single-writer applies within a transaction
>> but only one thread per transaction is tested; no guarantees multiple
>> threads per transaction will everr be supported ; they just "should" work at
>> the moment).
>>> * It seems that operations on DatasetGraphTxn do not throw checked
>>> exceptions. However, do these operations can throw an unchecked
>>> exception?
>> Yes.
>> But any exception is a sign of internal problems (or breaching concurrency).
>> No normal operation should throw an exception.
>>> * Does nested read transactions are allowed?
>> No.  No nested trasnactions at all.  But if you are in a read transaction
>> you can make as many reads as you want.
>>> *  When a StoreConnection is created with Location.mem() as location,
>>> what is created in memory (dataset+journal, only dataset or only
>>> journal)?
>> Everything is (should) be in-memory.
>> It's for testing only.
>>> * Does the information on the following webpages are up to date?
>>>    -
>> Should be.
>>>    -
>> May be not.
>> That was the design and no design survives first contact with implementation
>> reality
>>         Andy
>>> Kind Regards,
>>> Laurent

View raw message