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) 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 >>>> >>>> >>> >> >
