Kent Sølvsten wrote:
This is a tough, but interesting question ......
[SNIP]
A few ideas:
(1)
If the persistence engines in the entitystores are XA capable (such as
for JDBC/NEO4J entitystores) it should not be too difficult.
The basic idea would be to inject a DataSource provided by the
appserver
into the EntityStore and let the EntityStore avoid committing - leaning
on commit of the global XA transaction
- and postpone notifying indexers until the global transaction is
committed (we should be able to listen to "commit events").
I did just that with the SQL ES a few years ago.
I provided the SQL ES with a Connection that would delegate to a XA
Connection and avoid committing, letting the responsibility to commit to
the application server.
It's working in production since then. But it's nasty and I've been
lucky, especially because of the presence of an Indexer in that
application ....
One simple way to look at JPA integration would be to simply use Zest
without using its persistence related features.
i.e. "if you use JPA, you don't need (cough!) Zest persistance"
For this we could do various things to ease users pain:
- show (sample, doc, whatever) how one can use composites for e.g. only
their service layer while running in some horrid application server and
persisting with JPA
- have a Value <-> POJO converter, to move state from one world to the
other if you really want to
IOW, I'm note sure about the value of some JPA/UoW integration.
My 0.2 cents
