Werner,
Thanks for the feedback!
Are there specific challenges that the DEEP extended persistence context
inheritance (which can reduce memory footprint and has other scalability
advantages) would help JSR 350/351 with? Or is it more that the
improvements will give more flexibility that will likely be useful to
JSR 350/351?
I think the DEEP extended persistence context inheritance will be a
useful addition for many situations where you want to share the same
persistence context between multiple beans (in the same EJB container
instance).
Scott
On 06/07/2012 03:13 AM, Werner Keil wrote:
> I'd assume, at least JSR 350, potentially others like 351 could also be
> interested.
> And probably some vendors in the NoSQL scene. 350 EG starts gathering
> detailed requirements, but there is already a first initial codebase,
> too. JPA is a hot topic, and others, e.g. 351 also use JPA as
> "inspiration" for a query language that's more along the line of
> identity attributes. Think aspects of FBQL, but more secure and with
> better Privacy than Facebook;-) And of course vendor neutral.
>
> Werner
> --
> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
>
>
>
> Scott Marlow <smarlow_at_redhat.com> schrieb:
>
>
>
> On 06/04/2012 05:58 AM, Emmanuel Bernard wrote:
> > Hey all,
> >
> > I am of the opinion that both DAOs should share the same persistence context as they are both wrapped in the same Stateful SessionBean. Is there any reason why we should purposely not propagate the same persistence context?
>
> There are reasons why users would want to inherit the extended
> persistence context between sibling beans, as well as crawling multiple
> levels up the current bean call stack to inherit an existing extended
> persistence context.
>
> There are also reasons why users wouldn't want to inherit the extended
> persistence context between sibling beans (e.g. they want isolation) as
> well as inheriting only from the parent bean.
>
> Both possible inheritance approaches have their advantages and
> disadvantages. After thinking about t
> his for
> a few days, I am of the
> opinion that we should allow for both inheritance approaches in some
> fashion. That is if we can come up with a way for the developer to
> express which inheritance method is to be used.
>
> Perhaps something like:
> @PersistenceContext(type=PersistenceContextType.EXTENDED,
> inheritance=PersistenceContextInheritance.DEEP)
>
> @PersistenceContext(type=PersistenceContextType.EXTENDED,
> inheritance=PersistenceContextInheritance.SHALLOW)
>
> If there isn't enough interest in supporting both (useful) inheritance
> mechanisms, perhaps vendor extensions could be used instead.
>
> Scott
>
> >
> > While I understand the propagation and the reasoning, I do think that it"makes sense" for implementors and is sound but nevertheless miss the ease if use and practical test especially for beginners.
> >
> > It would be much easier for people to understand that SFSB sharing the sa
> me life
> cycle owner (the top SFSB in practice) share the same persistence context.
> > PC propagation and inheritance is quite complex to grasp despite the fact that we designed it to improve ease-of-use. I wonder if we can make it easier for people.
> >
> > Sure, the"fix" is one line of code, namely add the @PC to the root SFSB but the behavior is surprising and more than one beginner falls into the trap of not adding it and end up using 2 PC with at best performance issues and worse case, hard to understand identity breaks.
> >
> > Christian has expressed my opinion with stronger words but fairly aligned with my ideashttp://4thline.org/articles/Stateful%20persistence%20context%20propagation%20in%20JPA.html
> >
> > Emmanuel
> >
> > On 1 juin 2012, at 20:40, michael keith wrote:
> >
> >> Right, once the persist
> ence
> context is removed from the parent SFSB then there is nothing to inherit :-)
> >>
> >> On 01/06/2012 2:09 PM, Linda DeMichiel wrote:
> >>> There should be two distinct persistence contexts.
> >>>
> >>> On 6/1/2012 10:15 AM, Scott Marlow wrote:
> >>>>
> >>>> On 06/01/2012 12:47 PM, Linda DeMichiel wrote:
> >>>>>
> >>>>>
> >>>>> On 6/1/2012 9:25 AM, michael keith wrote:
> >>>>>> Assuming the DAO interface is local and does not have a @Remote on it,
> >>>>>> and also assuming that there is just a forgotten
> >>>>>> injection annotation of
> >>>>>> @PersistenceContext(type=PersistenceContextType.EXTENDED) on the EM in
> >>>>>> TestService, then the PC
> >>>>>> should be inherited by both SFSBs DAO1 and DAO2. If the sessi
> on
> beans
> >>>>>> are local then you should not leave the EJB
> >>>>>> container instance.
> >>>>>> (Does that answer the question?)
> >>>>>>
> >>>>>
> >>>>> Yes, agree.
> >>>>>
> >>>>> Scott, was TestService intended to have a transaction-scoped or an
> >>>>> extended persistence context?
> >>>>
> >>>> For the purpose of this question, lets remove the entity manager from TestService. I should of removed that before.
> >>>>
> >>>>
> >>>> @Stateful
> >>>> @Remote(TestService.class)
> >>>> public class TestSFSB implements TestService {
> >>>>
> >>>> @EJB(beanName ="DAO1") private DAO dao1;
> >>>> @EJB(beanName ="DAO2") private DAO dao2;
> >>>>
> >>>> public String testfunc() {
> >>>> dao1.myFunction();
> >>>> dao2.myFunction();
> >>>> return"fine";
> >>>> }
> >>>> }
> >>>>
> >>>> @Stateful
> >>>> public class DAO1 implements DAO {
> >>>> @PersistenceContext(type=PersistenceContextType.EXTENDED)
> >>>> private EntityManager entityManager;
> >>>>
> >>>> public void myFunction() {
> >>>> entityManager.find(PersonOrm.class, 123L);
> >>>> System.out.println("DAO1:" + entityManager);
> >>>> }
> >>>> }
> >>>>
> >>>> @Stateful
> >>>> public class DAO2 implements DAO {
> >>>> @PersistenceContext(type=PersistenceContextType.EXTENDED)
> >>>> private EntityManager entityManager;
> >>>>
> >>>> public void myFunction() {
> >>>> entityManager.find(PersonOrm.class, 123L);
> >>>> System.out.println("DAO2:" + entityManager);
> >>>> }
> >>>> }
> >>>>
> >>>>>
> >>>>>
> >>>>>> On 01/06/2012 11:50 AM, Scott Marlow wrote:
> >>>>>>> In the interest of ensuring EE application portability, I'd like to
> >>>>>>> change or add additional wording to the JPA 2.1
> >>>>>>> "7.6.3.1 <http://7.6.3.1> Inheritance of Extended Persistence Context" section.
> >>>>>>>
> >>>>>>> In the following example, instances of beans TestSFSB, DAO1, DAO2
> >>>>>>> will be"executing in the same EJB container
> >>>>>>> instance" (PostConstruct for { TestSFSB, DAO1, DAO2} should
> execute
> >>>>>>> in the same EJB container instance). One question
> >>>>>>> that I have, is there a possibility for { TestSFSB DAO1, DAO2} to not
> >>>>>>> execute in the same EJB container instance? Is
> >>>>>>> that EJB container implementation specific?
> >>>>>>>
> >>>>>>> @Stateful
> >>>>>>> @Remote(TestService.class)
> >>>>>>> public class TestSFSB implements TestService {
> >>>>>>> private EntityManager entityManager;
> >>>>>>>
> >>>>>>> @EJB(beanName ="DAO1") private DAO dao1;
> >>>>>>> @EJB(beanName ="DAO2") private DAO dao2;
> >>>>>>>
> >>>>>>> public String testfunc() {
> >>>>>>> dao1.myFunction();
> >>>>>>> dao2.myFunction();
> >>>>>>> return"fine";
> >>>>>>> }
> >>>>>>> }
> >>>>>>>
> >>>>>>> @Stateful
> >>>>>>> public class DAO1 implements DAO {
> >>>>>>> @PersistenceContext(type=PersistenceContextType.EXTENDED)
> >>>>>>> private EntityManager entityManager;
> >>>>>>>
> >>>>>>> public void myFunction() {
> >>>>>>> entityManager.find(PersonOrm.class, 123L);
> >>>>>>> System.out.println("DAO1:" + entityManager);
> >>>>>>> }
> >>>>>>> }
> >>>>>>>
> >>>>>>> @Stateful
> >>>>>>> public class DAO2 implements DAO {
> >>>>>>>
> @PersistenceContext(type=PersistenceContextType.EXTENDED)
> >>>>>>> private EntityManager entityManager;
> >>>>>>>
> >>>>>>> public void myFunction() {
> >>>>>>> entityManager.find(PersonOrm.class, 123L);
> >>>>>>> System.out.println("DAO2:" + entityManager);
> >>>>>>> }
> >>>>>>> }
> >>>>>>>
> >>>>>>>
> >>>>>>> Text from the JPA 2.0 specification:
> >>>>>>>
> >>>>>>> "
> >>>>>>> 7.6.2.1 <http://7.6.2.1> Inheritance of Extended Persistence Context
> >>>>>>>
> >>>>>>> If a stateful session bean instantiates a stateful session bean
> >>>>>>> (executing in the same EJB container instance) w
> hich
> >>>>>>> also has such an extended persistence context, the extended
> >>>>>>> persistence context of the first stateful session bean is
> >>>>>>> inherited by the second stateful session bean and bound to it, and
> >>>>>>> this rule recursively applies—independently of
> >>>>>>> whether transactions are active or not at the point of the creation
> >>>>>>> of the stateful session beans.
> >>>>>>> "
> >>>>>>>
> >>>>>>> Text from the JPA 2.1 specification:
> >>>>>>>
> >>>>>>> "
> >>>>>>> 7.6.3.1 <http://7.6.3.1> Inheritance of Extended Persistence Context
> >>>>>>> If a stateful session bean instantiates a stateful session bean
> >>>>>>>
> ;
> (executing in the same EJB container instance) which
> >>>>>>> also has such an extended persistence context with the same
> >>>>>>> synchronization type, the extended persistence context of
> >>>>>>> the first stateful session bean is inherited by the second stateful
> >>>>>>> session bean and bound to it, and this rule
> >>>>>>> recursively applies—independently of whether transactions are active
> >>>>>>> or not at the point of the creation of the
> >>>>>>> stateful session beans. If the stateful session beans differ in
> >>>>>>> declared synchronization type, the EJBException is
> >>>>>>> thrown by the container.
> >>>>>>> "
> >>>>>>>
> >>>>>>> Depending on the answer to my first questio
> n, I'd
> like to add
> >>>>>>> clarifying text (to the JPA 2.17.6.3.1 <http://7.6.3.1> section) that
> >>>>>>> makes it more obvious whether DAO1 + DAO2 (which could execute in the
> >>>>>>> same EJB container) will inherit the same
> >>>>>>> extended persistence context. I'll try to make some suggestions after
> >>>>>>> we have answered these questions as to whether
> >>>>>>> DAO1 + DAO2 will always execute in the same EJB container.
> >>>>>>>
> >>>>>>> Scott
> >>>>>>>
> >>>>>>>
> >>>>
> >>>
> >
>