On 11/04/16 20:30, A. Soroka wrote:
A separation was recently introduced by Andy between Transactional
(application-side interface) and TransactionalComponent (system-side
interface) interfaces, which I believe I understand and definitely
support. Additionally, a TransactionalNotSupportedMixin interface was
introduced in order to support "un-Transactional" behavior. It
extends Transactional and provides default implementations for the
methods in Transactional that throw UnsupportedOperationExceptions.
My question: should TransactionalNotSupportedMixin actually be the
"override" for Transactional (as it currently is), or for
TransactionalComponent, or oddly, for both? Would it be more
appropriate to introduce a new NonTransactionalComponent mixin or the
like? I suspect that it would be, because we want Transactional and
TransactionalComponent to be able to evolve with some real
independence, but I also suspect that I am missing something here.
{grin}
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.
A more complicated one is:
https://github.com/afs/mantis/blob/master/dboe-transaction/src/main/java/org/seaborne/dboe/transaction/txn/TransactionalComponent.java
where
1/ It's "begin(Transaction transaction)"
There is a Transaction object and transactions are not tied to threads
in the interface. The transaction knows if it is R or W.
2/ A lot more operations that only make sense where:
startRecovery / recover / finishRecovery
commitPrepare / commit / commitEnd
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.
E.g.
Every Java Map isn't a TransactionalComponent.
(For context, this came up for me looking at JENA-1084 as I try to
tease apart different kinds of behavior in the TxnInMem dataset impl
and amongst them, transactionality. That impl uses a design wherein
tuple tables, each for a particular order of columns, are coupled up
into multiplex tables that can support all queries. So the question
of how to correctly combine transactional and non-transactional code
is practical. I started using TransactionalNotSupportedMixin to mark
non-transactional implementation code, but now I'm confident that I
was wrong and that the "override" for TransactionalComponent is what
I really want, but it's not there! {grin})
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.
BSBM 5 million:
General/NoCache Space=4209.16 MB Time=30.93s
General/Caching Space=1927.53 MB Time=28.76s
TIM/NoCache Space=4656.02 MB Time=41.44s
TIM/Caching Space=2374.39 MB Time=38.21s
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.
Andy
--- A. Soroka The University of Virginia Library
