6 Replies Latest reply on Jul 15, 2008 2:27 AM by gromero

    POJO vs. SFSB vs. SLSB DAOs

    admin.admin.email.tld

      So I was just reading the Bauer and King JPA with Hibernate book.  pretty decent book BTW.


      on pgs. 514-515, they discuss transaction- and persistence-context propagation rules and scenarios.


      Write your DAOs as stateful EJBs if you write your controller as a stateful session bean.  This issue is another
      nasty side effect of the missing FlushModeType.MANUAL that can seriously impact how you design and layer
      applications.  We recommend you rely on the Hibernate extension until the EJB 3.0 specification is fixed.
      With FlushMode.MANUAL, your controllers don't have to use TransactionAttributeType.NOT_SUPPORTED, and the
      persistence context is always propagated along with your transaction (and you can mix stateless and stateful
      EJB calls easily).


      On pg. 509, one of the propagation rules is:


      If a stateless component is invoked, and the caller doesn't have an active tx, or the tx isn't propagated into
      the called component, a new persistence context is created when the EntityManager is called inside the stateless
      component.  In other words, no propagation of a persistence context occurs if no transaction is propagated.


      The controller above refers to conversation controller which is a SFSB.


      I'm trying to understand if you absolutely must use SFSB DAO's or not.  What are the repercussions of calling a DAO method from a SFSB in the following two scenarios:


      1) TransactionAttributeType.NOT_SUPPORTED (controller method)
      2) TransactionAttributeType.REQUIRED (controller method)


      What if the DAOs are POJOs (i.e., non-EJBs)?


      This section of the book is outside of a Seam context.  How do the rules apply in a Seam app?  Any difference in rules?


      Seems to me as long as there's an active transaction and the transaction gets propagated from controller method to DAO method, then the persistence context will be propagated as well.  So if you use a SFSB controller method with REQUIRED transaction type that calls a SLSB or SFSB DAO method with REQUIRED or SUPPORTS or MANDATORY, you should be good.


      So why must the DAO be SFSB??


        • 1. Re: POJO vs. SFSB vs. SLSB DAOs
          christian.bauer

          What are the repercussions of calling a DAO method from a SFSB in the following two scenarios:

          1) TransactionAttributeType.NOT_SUPPORTED (controller method) 




          If the DAOs are SLSBs, each DAO call will get a new persistence context when using @PersistenceContext injection - this is definitely not what you usually want. Propagation of the persistence context is bound to the system transaction - there is none, so no propagation. Because you run in auto-commit mode, the persistence contexts will not even be flushed automatically.


          If the DAOs are SFSBs (like the controller that does the calls), each DAO call will get the same context with @PersistenceContext injection. The controller SFSB is the client of the DAO SFSBs, it instantiates each DAO and it must remove() each of them. Propagation of persistence context is bound to this instantiation graph.




          2) TransactionAttributeType.REQUIRED (controller method)



          The same persistence context is propagated into any SFSB and SLSB DAO that uses @PersistenceContext. But the persistence context is also automatically flushed when the controller method completes (the system transaction completes). You don't want that in the middle of a conversation.





          What if the DAOs are POJOs (i.e., non-EJBs)?


          Then you don't have @PersistenceContext injection in the DAOs and the whole discussion is no longer about EJB 3.0.


          Forget all this stuff and use a Seam-managed persistence context with @In. It has been created and designed to avoid all of these propagation rules and to give you a single easy rule: It's one persistence context per conversation and you can inject it into ANY component AT ANY TIME during the conversation. Flushing of this persistence context is NOT BOUND to any transaction rule or transaction propagation. These are orthogonal concerns. Unfortunately, some members of the EJB 3.0 expert group don't see it that way.





          • 2. Re: POJO vs. SFSB vs. SLSB DAOs
            christian.bauer

            And this is definitely the last time I've explained this. It's all been documented a dozen times. I suggest that in the future any questions about it are directed to the people responsible for this nonsense: ejb3-spec-feedback@sun.com

            • 3. Re: POJO vs. SFSB vs. SLSB DAOs
              diegocoronel

              humm, if my DAOs are seam components and im going to have about 40 simultaneous users, what seam scope should i use ? what is your choice is this case Christian? Im using Event, is this ok ? also my facade.


              • 4. Re: POJO vs. SFSB vs. SLSB DAOs
                admin.admin.email.tld
                Well it will be interesting to see if the JSR299 will have any affect on the @PersistenceContext usage in EJB3.0 apps.  You'd think that they would merge this concept into JSR220 somehow to "update it"...

                I am going to email them and see what they have to say.  It seems a lot more complicated in terms of transaction and persistence context management when you can not use the @In to inject the EntityManager instance and set flushModeType=MANUAL (which I'm not sure they're adding to EJB3.1 but I'll find out).

                thx for the response, Christian.
                • 5. Re: POJO vs. SFSB vs. SLSB DAOs
                  admin.admin.email.tld

                  Well I emailed them this morning and no response yet.  Not a surprise...

                  • 6. Re: POJO vs. SFSB vs. SLSB DAOs
                    gromero

                    Hi.
                       I'm showing your posts. and I'm using my Daos extending EntityHome anda EntityQuery. This give you a persistent Context with concurrent control, because EntityHome and EntityQuery aren't EJB, but they are seam componets with default conversation Scope, and they Extends the PersistenceContext, I only use that to do CRUD. and list.


                        Its so recomendable for that to use EJB Stateful or Stateles component to List anda CRUD. Now if you need clurterizable components you have to implement yours DAOS with Stateless or Stateful EJB.