Okay, as I wrote, I have no objection to pulling out journaling for now. We can reintroduce it later if that seems useful. Alternatively, if you would rather fix it up to work with what you are doing, I can pivot to do that, but it will be a day or two at least. Sounds like the right move now is to excise it.
"Indeed DatasetGraphWithLock is really some sort of "storage DSG" (the current DSG interface before adding Transactional) and a transactional policy (which should be a parameter, not built in).” You mean some way of building a DSGWithLock using a wrapped dataset and a lock? Or using a wrapped dataset and some as-yet un-introduced type that represents policy abstractly? Boundary markers in streams of changes would indeed be great. I can think of at least one use case myself, from my $job— just plain logging changes into a human-intelligible journal. --- A. Soroka The University of Virginia Library > On Feb 3, 2016, at 4:38 AM, Andy Seaborne <[email protected]> wrote: > > Characterising the issues is the issue. > > I'm using JENA-1089 as a chance to do some clearing out. There are some DSG > implementations that are passed their use-by date. A mild attack of code rot. > > Some got written for some specific purposes, then left in case they were > "useful" (I guess). They are "general" style working with collections of > graphs from any storage. > > One definitely is only suitable for use inside a transaction - it provides > USING and WITH view support for SPARQL Update - and should not be seen > otherwise. > > For the journalling, if that's pulled out for now, I can get the changes done > with more degrees of freedom. Then we can put it back if need be. Its not the > journaling per se, it is the context in which it works. > > Indeed DatasetGraphWithLock is really some sort of "storage DSG" (the current > DSG interface before adding Transactional) and a transactional policy (which > should be a parameter, not built in). > > Andy > > A corollary of all this is I will be making suggestions for RDF Patch and > DatasetChanges to have transaction boundary markers ... I'm working on that > area for $job. Turns up to be really useful building block: > > * incremental backups > * geo replication > * maintaining a system-of-record > * moving live databases about > > JENA-1089 (Add Transactonal to DatasetGraph) is a necessary step. > > On 02/02/16 21:48, A. Soroka wrote: >> Not sure what you mean by status, but I’m happy to look at any > particular problems you’re seeing. I had no intentions of taking it any > further on its own, for now. The persistent datastructure direction > seems more interesting and profitable. I would be happy to straighten > out any mistaken overruns over DSGWithLock’s semantics. Where are those > documented? (For those who missed it, the journaling dataset came in as > an early attempt to move forward with transactional in-mem storage, and > seemed to work fine when the bulk of the work for JENA-624 that I did > got merged.) >> >> To be sure, the package is not in use in oaj.s.c.mem, which is where > the more interesting work ended up, and I cannot imagine that it is in > use by any great crowd since 3.0.1, so if you want to quash it, I’m not > going to cavil. We’ll always have the version history… >> >> --- >> A. Soroka >> The University of Virginia Library >> >>> On Feb 2, 2016, at 4:29 PM, Andy Seaborne <[email protected]> wrote: >>> >>> Adam - what's the status of this package? >>> >>> While working on JENA-1089, I found that DatasetGraphWithRecord isn't >>> calling up into the inherited abort(). In refactoring and tightening up >>> around DatasetGraphWithLock, tests detect an error. It also means changes >>> monitoring wasn't working. >>> >>> While fixing some other timing/concurrency tests, mysterious things are >>> breaking in DatasetGraphWithLock, which it uses. DatasetGraphWithRecord >>> seems to pin down the semantics of DatasetGraphWithLock beyond the contract. >>> >>> If this package isn't in use, I'd rather not spend time puzzling it all out. >>> >>> Andy >> >
