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

Reply via email to