PS
See the comments in TransactionalNotSupported
The Eclipse compiler flagged up errors when multiple routes to the same
implementation of a interface method happened. Whether it is right or
wrong by the language spec I don't know.
Hence the TransactionalNotSupportedMixin should be considered a failed
experiment.
Shall we remove it? It's only used in one place and that's in test code.
Andy
On 16/04/16 11:18, Andy Seaborne wrote:
On 14/04/16 21:17, A. Soroka wrote:
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?
What component are you thinking of?
DatasetGraph indicate it with "supportsTransactions() -> false"
and supportsTransactionAbort() for the "true, but no abort case" that
than a interface indicator.
TransactionalNotSupportedMixin is just a convenient shorhand for writing
out the cases of "unsupported".
And the style does not work every where - e.g. DatasetGraphMapLink where
multiple inheritance is needed as the Transactional part has state but
the class is already a subclass. (is there a better way round that? The
code uses pure "implementation inheritance" - i.e. a bunch of call
throughs on a private member.)
Mixin, to me, is an implementation style to add some functions to a
class without being a stateful super class. Kinda didn't work very
well, TransactionalNotSupportedMixin is only used once.
Though I read that using default methods in an interface like that is
bad style - I don't know why though.
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!
:-)
Let's close 1084. That's about i TIM good enough - it is.
Experimentation on better TIM is good and might result in some more
JIRA; first step is the experimentation and maybe looking at what other
datastructures are candidates.
If it's "copy on first write, then update in place (= same W
transaction, same thread)" no locking is needed. Which is good.
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
