Hi Andy, many thanks for your ideas and suggestions. Paolo wrote a check that covers most of your ideas. We'll implement the "missing" ones soon.
On 26.05.2012 20:19, Andy Seaborne wrote: >> customised the TDB code for our needs. For instance we introduced read >> caches shared between all stores (to avoid memory problems). Also we >> introduced basic capabilities to roll back transactions. (We took >> control over all data read from or written to ObjectFile and BlockMgr). > > Would you consider contributing your improvements back to Jena? Yes, of course. We will merge our changes if you find them useful. :-) Yet, at the moment the global cache is entangled with our transaction management. Since the latter is obsolete (TDB 0.9), we would prefer to integrate and contribute our changes to 0.9. >> So, in our situation we can't switch to the new TDB version over night. > > OK - as you probably know, transactions in 0.9.0 do provide robust update. Yes, we are burning to switch to the new version. But before we have to check, if we can open thousands of stores on a single machine without memory issues. Another crucial point is the possibility to sparql the original(=unmodified) data during a write transaction (from the same thread). This is necessary because we rely on the Delta (what was added to and what was removed from the Model) during a write operation. The ModelChangedListener is very helpful here. Unfortunately the MCL gets informed about any statement that is _requested_ to be deleted, independently of the existence in the store. The same holds for the added statements. So we decided to add logic that let us read the original data and check which statements are really removed or added. These things keep us from a fast switch. Nonetheless, as soon as we have time to, we'll check this out and implement it. And of course, if you like the changes and find them useful, we share it with the community. Thanks for your great semantic framework -- it's amazing. :-) Greetings from Hojoki André
