I've seen that happen (per language spec) when two implemented methods with the same signature are available via different paths of inheritance. That didn't used to be possible, but now it is via default methods. In fact, I saw that very thing in this case because I had a class that inherited impled methods from TransactionalComponent and also impled TransactionalNotSupportedMixin. I had to explicitly choose one or the other. Maybe that was what you saw?
I agree that TransactionalNotSupportedMixin isn't working very well right now. I think we should either remove it or document it to within an inch of its life. Even then, it doesn't save that much typing… --- A. Soroka The University of Virginia Library > On Apr 16, 2016, at 6:25 AM, Andy Seaborne <[email protected]> wrote: > > 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 >>> >> >
