polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: JPA?
Date Wed, 10 Aug 2016 20:21:41 GMT
This is a tough, but interesting question ......

I have seen a few other attempts at bridging the NoSql with the JPA world -
you could consider taking a look at DataNucleus or Hibernate OGM.

Both seem to generate native queries based on the JPA API (similar to
the Zest QueryBuilders) - and then attempt to integrate all changes with
the global (XA) transaction of the Application Server
(constrained be the presence/absence of XA support in the stores).

I am not quite convinced it would be the way to do this - the fit
between the Zest entities and the JPA API is not quite obvious to me -
but a similar strategy *should* be possible.

But is it really what is asked for?
 - would it be better to allow more seamless integration where parts of
an application is persisted in a traditional relational database (using
JPA), and other parts are "DDD/Zest" entities?
That could present a nice migration path, I think. And the integration
would be, not so much on the query/persistence part, but more in the
UnitOfWork/transaction part.

A few ideas:

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").

Abother possible strategy could be to let the UnitOfWork be a resource
managed by the appservers transaction manager - A lot more complex!
But maybe we could be able to use a "last resource gambit" - so the UOW
will need to be a resource managed by the TransactionManager, but at
least it should not be necessary to be XA compliant.

Another idea could be to separate the UOW completion from the "flush" to
the EntityStore(s).
Right now the "definition" of UOW#complete is flushing changes to the
EntityStore(s) - with the (eventual?) sideeffect of notifying indexers.

What if this was changed, so that the "definition" of UOW#complete is
persisting some record to a UnitOfWorkLog
- with the (eventual) sideeffect of flushing changes to EntityStore(s)
- with the (eventual) sideeffect of notifying indexers.
(actually this is not too far from eventsourcing - so maybe the
UnitOfWorkLog is simply an "EventStore"?).

The point is that the unitOfWorkLog could have a fixed schema, making it
suitable for an (XA-compliant) relational database.

A call flow could be:

- interceptor1 starts global transaction
- interceptor2 start UOW
- some changes are made to JPA entities
- some changes are made to Zest entities
- interceptor2 completes UOW (updates UOWLog record in a relational
- interceptor1 commits global transaction
- we listen for commit events and calculates/flushes changes to
EntityStores based on the UOWLog (this begin to look more and more like
an eventstore)
- with the sideeffect of notifying indexers....

Not simple, but maybe not too hopeless. Note that this could potentially
be useful in a Zest-only app with a single UOW leading to changes to
multiple EntityStores.



Den 31-07-2016 kl. 01:42 skrev Niclas Hedhman:
> I just came across something that has been discussed several times in the
> past. It is a anser on [1]
> <quote>
> When I read through the Qi4j in 2 minutes, 10 minutes etc. tutorials (the
> last one is incomplete), the one obvious question that came to mind was how
> do I integrate this with JPA/Hibernate managed entities? I would like to
> see a solution that seamlessly integrates with JPA. No JPA implies no Qi4j
> adoption in my opinion. I'd love to see an article by the author(s) that
> shows integration with JPA and Spring, two things that have deep
> penetration in the Java Enterprise world. If the integration is
> straightforward, rapid adoption will follow.
> </quote>
> As I said, this has surfaced several times in the past, and each time it
> has been discarded as "impossible" due to our models are significantly
> different from JPA in general and Hibernate in particular.
> Now, since we are breaking compatibility in a major way, the question that
> must be asked is;
>     Is there anything we can do to make this a possibility?
> Because, even though Hibernate has its serious issues, I think the post
> highlights the gist of the problem; Spring and Hibernate is popular. We
> should consider that fact seriously.
> [1]
> http://stackoverflow.com/questions/2196612/anybody-using-qi4j/9442920#9442920
> Cheers

View raw message