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:[email protected]] Gesendet: Sonntag, 6. Mai 2012 08:09 An: [email protected] 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> To: [email protected] > >> 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" <[email protected]> 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 <[email protected]> > >>> > >>>> 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" > >> <[email protected]> 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 <[email protected]> > >>>>> > >>>>>> 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-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 > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >> >
