Dienstag, 3. März 2009

Apache MyFaces Orchestra

Lately jsfcentral released a podcast which Kito recorded with Simon Kitching and me at JSFDays 2008.

This podcast is about Apache MyFaces Orchestra at its youngest days.

In the meantime a lot of things happend. One thing is, that I started to write a real Rich-Client application using Swing.
I had to reconsider everything ... My well known (so called) web-application-stack was no longer usable. No JSF, no Tomcat, no Servlets.
During this process I also thought about the database access layer. JPA is a great thing (I think), but some stuff around it is ... a hell.

As JPA implementation I use Hibernate which is also a great thing, but in the end, JPA does not necessarily make things easier.
The problem I have with ORM/JPA is the full transparency. It is funny, exactly this concept should makes things easier. But for me, it made things more complicated. It even forced me to build Apache MyFaces Orchestra to have a decent conversation scope.
Sure, I could have used JBoss Seam or Spring Web-Flow. But Web-Flow is to far away from standard JSF (for my opinion) and JBoss Seam ... I simply did not get how it worked.
However, with Orchestra there is simply a third choice, and all three choices are working very well ... if ... yes, if you would like work transparently with your entities (database objects).

  1. Transparently means, you change a property and somewhere at the end of the conversation a commit() finally persist it.
  2. Another thing which ORM solves are repeated reads of an entity with the same primary key. The ORM implementation will simply fetch it from the in-memory cache and you will always see the same instance.
    This is fine as if you changed the entity somewhere else you can be sure to see this change without having it persisted to the database.

Other stuff like lazy loading of associations or the database-independent creation of SQL statements can be expected from any other database access layer too, not neccessarily being 100% transparent, though.

Ok, (1) and (2) are really nice to have, but is it that a deficit not to have that?
I never managed to have that a perfect object hierarchy so that I did not have to call at least PersistenceContext.save(entity). Creating such a perfect object hierarchy is not easy and I doubt that it will lead to an overall performant database access.
And for (2): When are those repeated reads really necessary to being handled at "database session" level?
Even with Orchestra you can simply cache the entity yourself in the conversation-scoped backing bean of your JSF page. The only requirement which pops into my mind are "processes". Think about processes as various business modules of your appliation you compose together to a business-process.
But this composition will run normally within the same "transaction", so it is sufficient to have this "repeatable read" stuff working just for the "time of a transaction".
Hmmm ... I should write about that separately.

Once you buy that, you will find yourself writing easier maintainable programs. You just have full control over what happens when and why again.

To sum up:
  • Do not mind to call something like .save(), .delete()
  • Cache your entity as long as required and do not rely on "repeatable read"

The good thing is, that Orchestra is still usable in this scenario as the conversation scope is usable anyway - it defnitely will make your web-application development easier - but it is no longer required to have the persistence context being synchronized with the lifetime of the conversation. You simply use Orchestra without any PersistenceContextInterceptor.

The downside here is the requirements of JPA which will not play nicely here due to the "session" data it maintains to make all the transparency work.

Thanks to Simon Kitching who pointed me to Avaje I became aware of a library which works much like a JPA database access layer, but keeps a database session just for the transaction time. EXACTLY what I searched for.
Being able to stick with well known annotations, but without all the hassle you have with the 100% transparency "forced" by JPA.

My code did not change that much. But no session cache bloats my memory, no unused entities are hanging around in memory which you have to get rid somehow, no nested conversations if you e.g. navigate to a search page and back again.
It is hard to express, and a Blog is all about writing about personal feelings, but if you too think that JPA - as it is now - can't be the end, have a look at Avaje.
My next blog will be about Avaje ... stay tuned.

Keine Kommentare:

Kommentar veröffentlichen