Jukka Zitting wrote:
further note that write operations must occur within a single jdbc
transaction, i.e. you can't get a new connection for every store/destroy
operation.
I think this is a design flaw. On the other hand we require
persistence managers to be "dumb" components, but then we rely on them
for complex features like transactions.
I'd say those components are 'simple' rather than 'dumb' or 'complex'. the
requirements are therefore also relatively simple: operations must have A(C)ID
properties.
A) a change log must be persisted as a whole or not at all
C) this is actually handled by the upper level
I) while a change log is persisted a read must not see partially stored content
D) durability, well you get the idea...
to implement those requirements you don't necessarily need a database (as you
pointed out in another thread ;)).
regards
marcel
