From code point of view this architecture looks perfect. We have wrappers representing business objects. They all have persistent state, there are no stupid services in application called DogSaver with method save(DogEntity) which only call persist on entity manager. Code really gets a lot of readability and there some other advantages, but I dont wont go into details.

What really is my concern is this static EntityManager. I do not have enough knowledge about internals of Spring to know whether this approach is proper and safe. Are there situations where things mihgt get ugly?
I know that EntityManare is stateless (according to JPA spec), it always takes persistence context from transaction, thus making it static does not seem a bad idea. But I fear that I might be messing something.

<!-- Turn on AspectJ @Configurable support. As a result, any time you instantiate an object,
Spring will attempt to perform dependency injection on that object.
This occurs for instantiation via the "new" keyword, as well as via reflection.
This is possible because AspectJ is used to "weave" Roo-based applications at compile time.
In effect this feature allows dependency injection of any object at all in your system,
which is a very useful feature (without @Configurable you'd only be able to
dependency inject objects acquired from Spring or subsequently presented to
a specific Spring dependency injection method). -->
<context:spring-configured />
<tx:annotation-driven mode="aspectj" transaction-manager="transactionManager" />
<!--
Spring Security:
requires version 3.0.4 of Spring Security XSD: spring-security-3.0.4.xsd
<global-method-security ... mode="aspectj">
-->

I know @Configurable but it requires weaving and aspectJ. I don't have expreinece with those, but people who did try it, said it is not easy as it sounds from tutorials.
–
Paul SzulcAug 10 '11 at 8:05

Paul Szulc: I always use AspectJ for spring intead of this Proy AOP Stuff because it makes everything more predictable - (have a look at the thousends of Stackoverflow question which causes from the fact that proxy aop works only if you call the method from an other bean). On the other hand I have done several not trivial applications based on Spring Roo (the example above, is exactly what Roo does), and I never have had problems with the @Configurable stuff, even if I am not have so much experiance in AspectJ -- So i recommend: If you have time then give this idea a try.
–
RalphAug 10 '11 at 8:14

Raplph: do you know easiest way to make @Configurable work on a non-Roo project. Most importantly, how to make weaving happen automatically for entities when project is typical Maven project? I've seen people used surefire-plugin for Spring 2.5.6 no good example for Spring 3.0. (and there were changes in 3.0 that made examples for 2.5.6 impossible to reproduce).
–
Paul SzulcAug 10 '11 at 9:01

@Paul Szulc: I have extended the answer -- I use this feature since 3.0 so I don't know the differences to 2.5.6, and I do not know what surefire has to do with aspectJ -- anway that is a part of my current configuration
–
RalphAug 10 '11 at 9:49

The EntityManager is stateful (in a way). The factory is stateless. And having a static entity manager is an anti-pattern called "session per application" (or entity manager per application).

Note that these are implementation details - how is @PersistenceContext EntityManager em handled. Hibernate provides EntityManagerImpl which creates a new hibernate session if one isn't already created. But if it is already created, it holds a reference to it (the session=persistence context).

Having a static entity manager means it is not container-managed. Which in turn means that you are responsible for managing the persistence context.

What you are trying to do is Domain-driven design. Here is an article of mine about DDD and JPA.

My personal preference is not to go that way - the object should not be able to persist itself in a database - this is infrastructure logic. In order to avoid code duplication you can simply have a BaseDao which wraps the persist method. Or even directly use the EntityManager in your service layer. (This assumes you have clear layer boundaries)

If you are really sure you want to go the DDD path, take a look at the examples in the article. Spring allows you to inject the entity manager in any object, via aspectJ. So your entity manager will be properly handled, as well as your transactions.

I'm not exactly trying to achieve DDD, but this is not the issue right now. You said that EntityManager is stateful, but can you explain in what way it is stateful? Because from what I know EntityManager is 100% stateless. It always takes persistence context from transaction, each time you act upon it. What do you mean that EntityManager is stateful?
–
Paul SzulcAug 10 '11 at 8:01

the entity manager (and the underlying session) store all entities in a first-level cache. That's its state. And it is not thread-safe
–
BozhoAug 10 '11 at 8:14

well, it is not true. 1) persistence context is the one who is storing all entities (that is the first-level cache). Entity manger acts upon persistence context, but EM is not holding reference to persistence context - it always gets it from transaction. Secondly, yes, it is not thread-safe, but when you annotate @PersistencContext you get proxy to entity manager, not entity manager itself.
–
Paul SzulcAug 10 '11 at 8:35

What do refer to as "persistence context"? The EntityManagerImpl that hibernate provides simply wraps the hibernate Session, which holds a map of entities. You get the transaction from the manager, not the other way around.
–
BozhoAug 10 '11 at 8:42

in addition - hibernate provides a StatelessSession class, to contrast the standard session, which is stateful.
–
BozhoAug 10 '11 at 8:43