Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of laurent.pellegrino@gmail.com
 designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EAFD3B4.7010403@apache.org>
References: 
 <CAJWYrb186nwZOQ1MPwoXs1yf6JUYvJ1MDL1cWSY5oOPMXW1dgw@mail.gmail.com>
	<4EAD83D3.30802@apache.org>
	<CAJWYrb3-ja=jkH=nVbcnvMLFv2bmGwcFVbcuttcH59FuQeDbgg@mail.gmail.com>
	<4EAFD3B4.7010403@apache.org>
Date: Tue, 1 Nov 2011 15:17:02 +0100
Message-ID: 
 <CAJWYrb2xd+nkTDhcR-kjup5-DYOLj_KdsZZ0Nk=6NuFGGSpewA@mail.gmail.com>
Subject: Re: Transactional TDB
From: Laurent Pellegrino <laurent.pellegrino@gmail.com>
To: jena-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Adding a non-caching StoreConnection.createMem() is also doable.
>
> So I understand the use case, why do you want separate in-memory database=
s?

When I am running some tests (instantiating several datastores), I
prefer to use an in-memory datastore instead of a persistent
datastore. It will improve the execution time (e.g. for tests which
are I/O intensive) without affecting the result and without making any
difference when the purpose of the test is not to measure the
throughput of something. Moreover, if the test fail/crash, it avoids
to remove manually the repositories associated to the tests which have
crashed.

    Laurent

>> On Sun, Oct 30, 2011 at 6:05 PM, Andy Seaborne<andy@apache.org> =C2=A0wr=
ote:
>>>
>>> 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 tranactio=
n
>>> (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 transacti=
on
>>> but only one thread per transaction is tested; no guarantees multiple
>>> threads per transaction will everr be supported ; they just "should" wo=
rk
>>> 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. =C2=A0No nested trasnactions at all. =C2=A0But if you are in a read=
 transaction
>>> you can make as many reads as you want.
>>>
>>>> * =C2=A0When a StoreConnection is created with Location.mem() as locat=
ion,
>>>> 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?
>>>> =C2=A0 - http://openjena.org/wiki/TDB/Transactions
>>>
>>> Should be.
>>>
>>>
>>>> =C2=A0 - https://cwiki.apache.org/confluence/display/JENA/TxTDB-design
>>>
>>> May be not.
>>> That was the design and no design survives first contact with
>>> implementation
>>> reality
>>>
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy
>>>
>>>>
>>>> Kind Regards,
>>>> Laurent
>>>
>>>
>
>