hi @ all, @ a) +1
@ b) +1 for the basic concepts, however, @Transactional and @TransactionScoped need to be refactored (i'm currently working on it). furthermore, we should discuss a thin query layer which supports e.g. pagination,... easily (we also need it for a security-jpa module). regards, gerhard 2012/5/4 Mark Struberg <[email protected]> > Hi! > > It's time to start the discussion about our deltaspike-jpa module I think > ;) > > a.) where > I suggest that we create a ee-modules project with submodules jsf, jpa, > etc > > b.) what > *) @Transactional > *) TransactionalInterceptor with SimplePersistenceStrategy, > JtaPersistenceStrategy > *) ConfigurableDataSource, evaluate if we can make use of a special > PersistenceUnitInfo for JPA2 providers, but would that work in EE > containers as well? > > Because I often get asked if we can add this: I think we do _not_ need to > cover the (imo) broken Exception handling stuff which spring introduced in > their transaction interceptor. An Exception is an Exception is an > Exception! Logical return values and Business results must get propagated > via standard java return values or content holder objects. > > Oki the details: > > 1.) @Transational > > I suggest that we temporarily implement the javax.transaction.* stuff of > the _new_ Transaction Specification in DeltaSpike. We can take parts from > OpenEJB, some JBoss api stuff (as far as covered by the grants) and various > geronimo spec jars [1] > Once the spec is finished, we will move all the transaction-api.jar stuff > over to geronimo-specs [1]. Since this all is ALv2 it will be no problem > for JBoss folks to also just take the code and provide it in the JBossAS > project once we are finished. > > 2.) I like the way we implemented the TransactionalInterceptor in CODI > [2]. Our interceptor basically does exactly ... *nothing* ;) > All the work is done via an @Dependent PersistenceStrategy which gets > injected into the interceptor. @Dependent because then we don't get any > interceptor and it's really fast. > The BIG benefit of this little trick is that we are able to provide and > use DIFFERENT PersistenceStrategies! A user can use @Alternative, > @Specializes etc to define which PersistenceStrategy he likes to use in his > project. > > By default I'd like to provide the following PersistenceStrategies: > * SimplePersistenceStrategy: does just flush on all involved > EntityManagers and afterwards a commit. Not JTA transaction save, but good > enough for most use cases > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control > the EntitaManagers. This needs some exploration how we can do it. David > Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of > kind of the features of EJB standard transations, but NOT just for an EJB > invocation, but @RequestScoped! The first invocation starts the > UserTransaction, the @Disposes closes it. Just an idea ... > > > 3.) ConfigurableDataSource > You all know the dilemma: you cannot make a JNDI configuration in a way > that this stuff works with multiple EE servers since the locations where > you have your DataSource configured will pop up under different locations > in JNDI (based on which EE server/version you take). Otoh I don't like to > hardcode my credentials to the persistence.xml neither. > > Thus we came up with the ConfigurableDataSource [3]which just moves this > information to a CDI bean where you can use > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even > programmatic lookup!. I call this 'typesafe configuration'... > > > > Oki, any other ideas? > > LieGrue, > strub > > > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/ > > [2] > https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java > > [3] > https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29 >
