11 Replies Latest reply on Jun 1, 2006 7:29 AM by Hoagie X

    Plain DAO's and @PersitenceContext

    Hoagie X Newbie

      How can I get a plain old DAO to function with the @PersistenceContext WITHOUT turning the DAO into a bean of any kind?(since a DAO should obviously not be an EJB)


      This code fails when it is put to work as it is, but it works if I turn it into a stateless Session.

      public class MyDAO
      {
       @PersistenceContext
       protected EntityManager manager;
      
       createEntity(String someAttribute)
       {
       Entity myEntity = new Entity();
       em.persist(myEntity);
       }
      }
      


      So basically.... how can this be turned into a functioning POJO DAO?

        • 1. Re: Plain DAO's and @PersitenceContext
          Emmanuel Bernard Master

           

          "Hoagiex" wrote:
          How can I get a plain old DAO to function with the @PersistenceContext WITHOUT turning the DAO into a bean of any kind?(since a DAO should obviously not be an EJB)

          EJB 3.0 SB == POJO
          DAO == POJO
          EJB 3.0 SB == DAO

          Forget what you know about EJB 2.x, be cause it's 'obviously' wrong ;-)


          • 2. Re: Plain DAO's and @PersitenceContext
            Hoagie X Newbie

            Not to start a discussion on development and design rules...
            ...But if you start treating Session beans like DAO's, you end up with:
            A) Facade's with 10k line of code
            B) Session Facades calling Session DAO's (which is a total waste of resources since JNDI lookups, even internal ones, aren't exactly 'lightweight' operations)

            You wouldn't want either of these options and I feel you are suggesting option B.... well..... 'JNDI lookup BAAAAAAD' must prevent it as much as possible.

            If an entire chain of objects must be turned into 'Session beans' simply to be able to use the entity manager, EJB3.0 would be in a world of hurt, because not a single Enterprise-sized application could be buildt with it then, since a basic operation can string between depths of 2-15 objects.
            You want to turn all of these into session beans?

            • 3. Re: Plain DAO's and @PersitenceContext
              Hoagie X Newbie

              But I wasn't asking what I should 'change' on the design... I was asking if it can be done in the current design.

              We are testing the EJB3.0 technique and, although easy to program, it is lacking in some departments (we possibly overlooked something?). I would like to be informed if my question can be anwsered before I write off EJB3.0 as a new standard for my company.

              We have been using Hibernate for some time, and this never gave us any problems of this kind. Hibernate is also somewhat buggy, but it doesn't interfere with basic design patterns.

              • 4. Re: Plain DAO's and @PersitenceContext
                Emmanuel Bernard Master

                Would you explain to me why an internal JNDI lookup is not lightweight? This is basically a hashmap lookup.
                I stand on my position, use a SB to implement your DAOs

                On a design pattern, you have a motivation section (and sometime a context section), apply DP only if the motivation and context match.
                Java EE 5.0 design patterns are not a copy pastle of J2EE DPs.

                • 5. Re: Plain DAO's and @PersitenceContext
                  Hoagie X Newbie

                  Even hashmap lookups get heavy when the map is loaded with a piles and piles of objects.

                  On the DP's, don't kind yourself.... techniques come and go, the core DP's (these are not limited to Java, but are universal) are pretty much forever.

                  But the problem is that I have an basic application:

                  Facade--> AS --> AS --> DAO -->Entity
                  |__>DAO-->Entity

                  Why in heavens name, would I want to add a service locator between my As and DAO? Can you spell U S E L E S S O V E R H E A D? Not to mention the additional possible bottleneck of the locator.

                  For you basic homegrown application this might seem fine, but I talking about an application with a steady rate of over 10k+ active users.... A little addon like Session DAO's and Service Locators will add a substantial amount of required process power.

                  Is there anyone who can tell me how to obtain an Entity Manager in a DAO, without turning the DAO into a Session?

                  • 6. Re: Plain DAO's and @PersitenceContext
                    Hoagie X Newbie

                    Forgot code layout..

                    The 2nd DAO should be attached to the first AS, not the Facade ofcourse.

                    • 7. Re: Plain DAO's and @PersitenceContext
                      Stefan Arentz Newbie

                       

                      "epbernard" wrote:
                      Would you explain to me why an internal JNDI lookup is not lightweight? This is basically a hashmap lookup.
                      I stand on my position, use a SB to implement your DAOs

                      On a design pattern, you have a motivation section (and sometime a context section), apply DP only if the motivation and context match.
                      Java EE 5.0 design patterns are not a copy pastle of J2EE DPs.


                      I think it would be nice to have an 'EJB3 Design Patterns' forum here on JBoss. Many people are discovering new patterns for doing things EJB3 style and it would be a good thing for EJB3 and JBoss to discuss those in public I think.

                      S.


                      • 8. Re: Plain DAO's and @PersitenceContext
                        Anders Hedstrom Novice

                         

                        Why in heavens name, would I want to add a service locator between my As and DAO?


                        Why in heavens name, would you want to use a service locator between your As and DAO?

                        • 9. Re: Plain DAO's and @PersitenceContext
                          Hoagie X Newbie

                          Just implemented the DAO's as Sessions that are aquired by the POJO AS through a DAO Factory that does the JNDI lookup by menas of a ServiceLocator.

                          result:
                          8.1% increase in response time with 100 users
                          13.4% increase in response time with 1.000 users
                          16.9% increase in response time with 10.000 users

                          Does anyone have a good idea on how to avoid turning DAO's into Sessions and still have access to the EntityManager in a transaction context?

                          • 10. Re: Plain DAO's and @PersitenceContext
                            Hoagie X Newbie

                             

                            "anders.hedstrom" wrote:
                            Why in heavens name, would I want to add a service locator between my As and DAO?


                            Why in heavens name, would you want to use a service locator between your As and DAO?


                            Because JNDI code doesn't below in an Application Service?

                            • 11. Re: Plain DAO's and @PersitenceContext
                              Hoagie X Newbie

                              And dependency injection is also not an option since it would involve:
                              A) turning even more non-EJB objects into EJB objects
                              B) would 'inject' a lot of unused objects since not every AS method uses each EJB or Resource that is injected.