deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <>
Subject Re: [DISCUSS] deltaspike-jpa module features
Date Fri, 04 May 2012 20:50:29 GMT
hi @ all,

@ a)

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


2012/5/4 Mark Struberg <>

> 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]
> [2]
> [3]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message