On 01/08/13 22:18, Claude Warren wrote:
Mike poses an interesting question.
Should we add transaction boundaries to all the tests? I think there are 3
choices:
1) do not add transactions and developers like Mike will have problems with
environments that require transactions.
Can't @Before and @After (@BeforeClass, @AfterClass) be used by an
inheriting class?
2) add a switch that allows transactions to be enabled for the test and
have the TestingModelFactory specify if it is on or off.
3) turn on transactions in the tests by default. The assumption here is
that all Model implementations will support the transaction calls.
But they don't!
4) use the Model.supportsTransactions() method to determine if the
transaction should be used within the test.
I would lean toward 3 or 4.
Claude
Transactions are on datasets. Models are either free standing or a view
of a dataset. They will have different characteristics.
Fuseki adds a parallel "Transactional" object for in-memory data that
provides MRSW concurrency. That can be added to in-memory datasets by
default if there is any demand for it.
[ Aside:
The Model interface has the begin() style transactions, which lead to
issues of lock promotion, which in turn result in the possibility of the
system having to abort transactions because of lock incompatibilities.
That's why datasets provide begin(read/write) -- no lock promotion
issues, true parallel multiple-reader-single-writer, and fully
serializable transactions.
]
I wonder if there is a "Jena3" thing here to go back and review the
transaction contract and get the API sorted out if necessary. I'm not
sure applications working on models from datasets get the best contract
currently.
Andy
