On 24/12/13 20:00, Arto My Friend wrote:
Thanks Andy,
I ran smoothly with Sun JVM "1.7.0_45"
Jena-lib 2.11.0
Jena-TDB 1.0.0
Jena-spatial 1.0.1
Which is supposed to be the latest release version? (not nightly build)
Yes apache-jena-libs 2.11.0 (type POM) for the core stuff and
Jena-spatial 1.0.1
I am ok with transaction pattern now, so probably this is just for bug
investigation.
Art
On Tue, Dec 24, 2013 at 6:17 AM, Andy Seaborne <[email protected]> wrote:
On 23/12/13 18:00, Arto My Friend wrote:
Thanks a lot Andy, it's very helpful insight.
Knowing about expected usage pattern, I decided to change my approach
passing primitive Java type out of triple, rather than sending Jena's
Resource around.
Anyway, to my own curiosity as well, I can assure you that the first
example is actually working. (A bug or feature?)
Here is the gist I made for you to try out with maven dependencies
https://gist.github.com/ultra-nabito/8101569
Great thanks.
I get:
Exception in thread "main" com.hp.hpl.jena.shared.ClosedException: already
closed
at
String s = user.getProperty(PROP_UUID).getString();
which version are you running?
By the way, I still not clear on what you mean by 'models are just views
on
the dataset at a particular transaction time'
if for sometime later the data in TDB get updated, do I need to do
dataset.
begin(ReadWrite.WRITE);; and dataset.getDefaultModel(); again so to get
Model object that reflects the changed data?
Yes. Once you start using transactions, you should always use transactions.
For historical reasons, TDB will work without (and it's not autocommit).
In practical terms, and the current codebase :-), a Graph from TDB is just a
way of filling in the 4th slot of a quad or using the default graph tables.
Models in Jena are built around Graphs and the only additional state is some
caching.
So Models are effectively database views with a specific API.
Andy
Art
On Mon, Dec 23, 2013 at 11:30 PM, Andy Seaborne <[email protected]> wrote:
On 23/12/13 10:56, Arto My Friend wrote:
My code was working fine, creating a resource and later read from it..
Dataset dataset = TDBFactory.createDataset(TDB_PATH);
dataset.begin(ReadWrite.WRITE);
model = dataset.getDefaultModel();
String uid = generateUUID();
Resource user = model.createResource(BASE_URI + RES_PREFIX_USER +
uid)
.addProperty(PROP_HAS_CHECKIN, model.createSeq(BASE_URI + RES_PREFIX_REC
+
uid))
.addProperty(FOAF.mbox, email)
.addProperty(PROP_UUID, uid);
dataset.commit();
model.close();
dataset.end();
String uid = user.getProperty(MobiSosCore.PROP_UUID).getString();
However, after I changed the way I retrieve dataset to be
Dataset baseDataset = TDBFactory.createDataset(TDB_PATH);
EntityDefinition entDef = new EntityDefinition("entityField",
"geoField");
dataset = SpatialDatasetFactory.createLucene(baseDataset, INDEX_DIR,
entDef);
The program throw out ClosedException at the call of getProperty().
It seems to me that after base dataset is joined with spatial index, the
retrieved resource cannot be read outside a transaction block.
Please help. I want to know what underlying mechanisms that I should
understand to get my code right?
I'm surprised it works the first way at all - when I tried to write a
test for it, I get ClosedException when accessing the resource after the
model is closed.
The text daatset example looks correct. model is closed so
user.getProperty should throw an exception. If you've done "model.close"
all access to the model should cause the exception and "user" contains a
reference to the model internally.
If you have a complete, minimal example, could you send it and I can
debug
it.
When used with TDB, models are just views on the dataset at a particular
transaction time. The model.close isn't necessary although you may wish
to
do it, but do it inside the transaction because you, correctly, got the
model inside the transaction. (History: when we have BDB support, closing
things properly was essential as it release BDB resources.)
Things can't pass the transaction boundary although given the internal
details of TDB (it's effectively a MVCC system) it is possible some can
work much fop the time (later updates may break them).
Good use is to nest inside a transaction and what is inside a transaction
is scoped to the transaction.
Andy
Art
