deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject AW: [DISCUSS] deltaspike-jpa module features
Date Sun, 06 May 2012 09:17:01 GMT
Hi,
I think we have different dimensions here:
1. Who manages the transaction: JTA vs. RESOURCE_LOCAL (which basically means, should entityManager.joinTransaction()
or entityManager.getTransaction().begin() be used in an @Transactional interceptor)
2. From where can the datasource be obtained: From JNDI or is it defined via the persistence
properties
The third (minor) dimension that applies only if the datasource comes from JNDI: Is it a jta-
or non-jta-datasource

So the first dimension has to be respected when talking about transaction-management
and the second, when talking about datasource-configuration.

So, as I see, currently we are talking about the second:
Now the question is, how to configure the datasource in both scenarios. And both can be done
with the ConfigurableDataSource:
First scenario: The datasource is obtained from JNDI: Then the ConfigurableDataSource needs
to be registered in JNDI. In Java-EE-Containers this can be done with the @DataSourceDefinition
annotation. In plain Tomcat or Jetty servers this needs to be configured in a container-specific
way.
Second scenario: The datasource is configured via persistence properties. Then the ConfigurableDataSource
can be configured like described in the CoDI wiki.

How can deltaspike help people here? First of all we provide the ConfigurableDataSource and
thus enable DataSource configuration via CDI.
In addition, if we provide some kind of EntityManagerProducer, we can override the persistence.xml
via the additional properties map, that can be handed over to the createEntityManagerFactory
and createEntityManager methods.
For JNDI, we can register a ConfigurableDataSource with the @DataSourceDefinition under a
deltaspike-specific name and then give this datasource to JPA by setting the javax.persistence.jtaDataSource
or javax.persistence.nonJtaDataSource property in the map.
For non-JNDI we can change the javax.persistence.jdbc.driver property to point to our ConfigurableDataSource.

We even could provide a mechanism to change from JTA to RESOURCE_LOCAL (i.e. for production
vs. testing) by specifying the javax.persistence.transactionType property.

What do you think about this?

Cheers,
Arne

-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com] 
Gesendet: Sonntag, 6. Mai 2012 08:09
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS] deltaspike-jpa module features

@Mark: today using your own datasource implementation with @datasourcedefinition you answer
your need. The drawback compared to producers is you need to test the env where producers
will have stereotypes but it does the job even for complicated envrt.

- Romain
Le 6 mai 2012 05:02, "Jason Porter" <lightguard.jp@gmail.com> a écrit :

> Wasn't there another company, Software Mill?, which had some 
> persistence stuff we liked during formation?
>
> Sent from my iPhone
>
> On May 5, 2012, at 16:14, Mark Struberg <struberg@yahoo.de> wrote:
>
> > Yes, we should first concentrate on the other 2 things. We can try 
> > to
> find an even better solution than the ConfigurableDataSource.
> >
> > But I fear the @DataSourceDefinition from EE6 is completely useless 
> > for
> most real world apps.
> > The problem which I see with it that you can only have 1 of it per
> 'real' DataSource. Of course that would change if there would be a way 
> to create the 'real' DataSource via CDI producers.
> >
> > But I have no idea yet how to hand over a CDI produced DataSource to 
> > a
> JPA.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Romain Manni-Bucau <rmannibucau@gmail.com>
> >> To: deltaspike-dev@incubator.apache.org
> >> Cc:
> >> Sent: Saturday, May 5, 2012 11:29 PM
> >> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>
> >> With my note on datasourcedefinition i wanted to avoid to add sthg new.
> I'd
> >> prefer to fix existing API/specs.
> >>
> >> Adding sthg new simply creates another mess...no?
> >>
> >> - Romain
> >> Le 5 mai 2012 22:39, "Paul Dijou" <paul.dijou.dev@gmail.com> a 
> >> écrit :
> >>
> >>> Hi,
> >>>
> >>> Big +1 for all suggestions from Mark.
> >>>
> >>> Also +1 for some util classes for common operations like CRUD and 
> >>> pagination. Maybe inspiration from Seam Application Framework 
> >>> (Home,
> Query,
> >>> Controller) in Seam 2 [1] or from DataValve [2].
> >>>
> >>> Regards,
> >>>
> >>> Paul.
> >>>
> >>> [1]
> >>>
> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.
> html
> >>>
> >>> [2] http://www.andygibson.net/blog/projects/datavalve/
> >>>
> >>> 2012/5/5 Romain Manni-Bucau <rmannibucau@gmail.com>
> >>>
> >>>> Maybe using a datasource bean managed by cdi as a jpa datasource
> >> source
> >>> can
> >>>> be added to jpa or cdi (it is always a bit hard to decide which 
> >>>> specs qhould contain a new feature ;))?
> >>>>   Le 5 mai 2012 00:55, "Romain Manni-Bucau"
> >> <rmannibucau@gmail.com> a
> >>>> écrit :
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> isn't the ConfigurableDataSource in JEE6?
> >> (datasourceconfiguration by
> >>>>> annotation or in the web.xml)?
> >>>>>
> >>>>> a really really big +1 for a pagination solution (typically a
> >> hades
> >>> light
> >>>>> is a must have!)
> >>>>>
> >>>>> - Romain
> >>>>>
> >>>>>
> >>>>> 2012/5/4 Gerhard Petracek <gerhard.petracek@gmail.com>
> >>>>>
> >>>>>> 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 <struberg@yahoo.de>
> >>>>>>
> >>>>>>> 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-modu
> les/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jp
> a/impl/transaction/TransactionalInterceptor.java
> >>>>>>>
> >>>>>>> [3]
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDa
> taSource%28sincev1.0.2%29
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>

Mime
View raw message