On Apr 12, 2016, at 8:24 AM, Andy Seaborne <[email protected]> wrote: > A "Transactional" is the client facing API for the whole set of components > going to make the sub-system. > "TransactionalComponent" is what makes up "Transactional"s. For TIM, they > look quite similar because there is no worrying about stuff on disk or > recovery.
Okay, good, my starting understanding was basically right. <Mantis example snipped> > I'm not sure what a component that does not offer transaction support would > mean - either it's transaction oblivious, so does not need the interface, or > its controlled by a component, in which case the TransactionalComponent-ness > is elsewhere. Transaction/non-transactions is a feature fo the combined set > of components. If one does not play the game and is needed, the match is off. I didn't do a good job of expressing my problem. It's not the case that you describe, where a component simply doesn't support transactions. It's the case where a contracting type would be expected to support transactions but doesn't because of impl limitations. For example, a DatasetGraph extends Transactional, but some DatasetGraphs really can't support transactions. My understanding was that that's the point where you bring in TransactionalNotSupportedMixin, to indicate that fact, and I was looking for the equivalent for TransactionalComponent. But maybe I am misunderstanding TransactionalNotSupportedMixin? > I was looking at space used for the new parser caching but a side effect is a > few preliminary timing figures. > Here are updated figures for Jena latest with dexx 0.6, one run to warm up > the JIT first. <figures snipped> > dexx 0.6 didn't make a noticeable different and it looks like TIM is > acceptably slower and does not use much more space. > > Now, whether there are optimizations in TIM that can bring down the time, is > the big question. Well, this may make JENA-1084 pointless, in the best possible way! Yes, I think there are optimizations available. How much they will do, I can't say with any certainty. But I can certainly start looking at them. The one that I would most like to work on would be the use of "mutate-in-place" extensions for the persistent data structures, but Dexx isn't contemplating that (it's basically a port of the Scala data structure library) and I'm not sure how easy it would be to "graft" that on. There's also the fact that ideally, we would like "in-place" to mean "in a transaction", but unlike Mantis, we don't yet have a real object that is the transaction. We're still letting threads stand in for that. --- A. Soroka The University of Virginia Library
