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}
(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})
---
A. Soroka
The University of Virginia Library
