Hi Anıl, As an advice, in your application, you can insert the transaction operations at the beginning (dataset.begin()) and end (dataset.commit(), dataset.end()) of each request-response cycle, Also, dataset.rollback() to a generic exception handler. Thus, your beans can operate in transaction without noticing it.
Best, Tayfun 2013/1/24 A. Anil SINACI <[email protected]> > Hi Andy, > > Thanks for your reply. The wise thing would be restructuring through the > transactional mode of TDB as you also point out. > > Best, > Anil. > > > On 23.01.2013 23:25, Andy Seaborne wrote: > >> On 23/01/13 14:50, A. Anil SINACI wrote: >> >>> Dear Jena users, >>> >>> I need an advice on whether to use transactional TDB or >>> non-transactional one, and if I use non-transactional; when to use >>> TDB.sync. >>> >>> As far as I understand from the tutorials, if I have never call a >>> transaction operation on a dataset (i.e. dataset.begin(..)), then my TDB >>> backed dataset is used in a non-transactional mode. With this kind of >>> usage, I think I need to properly sync database in order not to put the >>> data files into an inconsistent state. I hope I am correct up to this >>> point. >>> >> >> Correct. >> >> >>> I have a web application which uses Jena TDB as its data store. Multiple >>> users are signin-in in and manipulating data. My current problem is >>> that, if the JVM holding the servlet container shuts down (i.e. ctrl+c >>> command), and if I run the server again, then I get a >>> NullPointerException during the dataset creation: >>> "TDBFactory.createDataset(...)**;". I tried to avoid this exception with >>> TDB.sync after each write operation that I do, however this decreases >>> the performance a lot. >>> >>> I can afford some missing information in the persistent store, however >>> the store becomes unreadable if closed (actually the JVM shuts down) >>> without a TDB.sync. On the other hand switching to transactional TDB >>> means that I need to employ a different architecture which will cost >>> much to me. To illustrate I want to give a small example, my bean-like >>> classes all extend OntClassImpl, hence in their constructors I call >>> "super(node, graph);" which automatically adds the corresponding triples >>> to my graph. It will be hard to edit this architecture to insert the >>> begin and end parts of transactions. >>> >> >> Lack of sync() does not miss some specific triples - it will loose some >> internal datastructure data so the database will be corrupt and unusable. >> There isn't a trade off to >> >> You can use transactions - it should be faster than needing to sync at >> every point. >> >> Open a transaction at the beginning of the web app operation and commit >> it at the end. Transactions are per-thread so concurrency on the same >> database will work. If you do not use transactions, you need manage >> concurrency yourself (or get a corrupt database, if TDB does not notice >> with it internal checking). >> >> If you know it's a read operation use a READ transaction. They are more >> efficient as well as being good practice. >> >> So, roughly >> >> web_operation() >> { >> dataset.begin(WRITE or READ) >> try { >> yourCode(dataset) // no concurrency control needed. >> commit() >> } .... >> >> >> and yourcode does not have to be transaction aware. >> >> Andy >> >> >
