6 Replies Latest reply on Apr 21, 2005 8:33 AM by Bill Burke

    Collections with null bug/feature/problem ...

    Emmanuel Bernard Master

       

      fails with a TxRollback because of a foreign key constraint

      If non cascade is enable you have to manually remove the objects in the appropriate roder yourself

      it throws a lazy Init execption

      Because you try to access a lazy entoty/collection outside of the session scope. You have to be sure to initialized your needed data before leaving the session bean scope (ie the entity close).

        • 1. Re: Collections with null bug/feature/problem ...
          Jens Elkner Apprentice

           

          "epbernard" wrote:
          fails with a TxRollback because of a foreign key constraint

          If non cascade is enable you have to manually remove the objects in the appropriate roder yourself

          it throws a lazy Init execption

          Because you try to access a lazy entoty/collection outside of the session scope. You have to be sure to initialized your needed data before leaving the session bean scope (ie the entity close).


          Can you explain that a little bit deeper, please? I#m not sure, what you mean with "session", since that's something, which is never mentioned in the specs nor I directly interact with (i.e. I nerver call open session etc.). What I do, is:

           TreeNodeEntityDAO dao = (TreeNodeEntityDAO)
           ctx.lookup(TreeNodeEntityDAO.class.getName());
           List<TreeNodeEntity> list = dao.getRoots();
           for (TreeNodeEntity e : list) {
           print(e, "");
           }
          with:
           public void print(TreeNodeEntity node, String ident) {
           System.out.println(ident + node.getName());
           String nident = ident + " ";
           Collection<TreeNodeEntity> list = node.getChildren();
           for (TreeNodeEntity e : list) {
           print(e, nident);
           }
           }
          
          and in the DAO class on ther server:
           public List<TreeNodeEntity> getRoots() {
           Query q = manager.createQuery("SELECT e FROM TreeNodeEntity e "
           + "WHERE e.parent=null");
           return q.getResultList();
           }
          


          Do you mean, that the list of beans I get, are all unmanaged and that's why e.getChildren does not work?

          • 2. Re: Collections with null bug/feature/problem ...
            Bill Burke Master

            Objects become detached once the transaction finishes.

            • 3. Re: Collections with null bug/feature/problem ...
              Jens Elkner Apprentice

               

              "bill.burke@jboss.com" wrote:
              Objects become detached once the transaction finishes.


              OK. But the question is "when is a tx finished?" Do I need to understand tx in EJB as in JDBC ?

              If so, I would think, that after each " return query.*" or manager.{persist|flush|refresh|remove|merge} an entity is in a detached state and so accessing lazy fields (even on the server side) would cause an error/exception. So lazy stuff is only ment to be a optimization hint to the manager (so that it does not load everything aka whole hierarchy) but not to be an optimization for a client, to ask for loading the stuff, when it is required?

              And just to make sure (summarizing that), am I right, if I say, a [remote] client deals always with detached entities?

              Or is tx in EJB3 considered to be the lifecycle of a SFSB? In this case, this would imply, that one has to access entities with lazy fields always via a SFSB to be able to use the fields at a later time? If this is right, am I right, that all entities are in the bean session context and thus tremendously increase the resource usage/requirements e.g. wrt. RAM ?






              • 4. Re: Collections with null bug/feature/problem ...
                Bill Burke Master

                I mean JTA transaction.

                By default in EJB 3, each Session bean method (MDB too) is TransactionAttributeType.REQUIRED This means, if a transaction hasn't been started, one will be started and committed/rolledback at end of the method call automatically. The EntityManager will automatically be registered with the transaction when you access it within the context of a JTA tx.

                So, in small words, you should understand what a JTA transaction is.

                • 5. Re: Collections with null bug/feature/problem ...
                  Jens Elkner Apprentice

                   

                  "bill.burke@jboss.com" wrote:
                  By default in EJB 3, each Session bean method (MDB too) is TransactionAttributeType.REQUIRED

                  Ah - ok (I have that probably overseen somewhere :(((). And the "no session" excepion than actually means "access outside of a tx"

                  So, in small words, you should understand what a JTA transaction is.


                  Yepp - thanx a lot for making this clear! Now its also clear, that lazy entity stuff is not accessable by clients via the entity itself :( ...



                  • 6. Re: Collections with null bug/feature/problem ...
                    Bill Burke Master

                    Remember, entities are POJOs. Hence the laziness...

                    If you want to fetch a lazily loaded relationship as part of a query, you can FETCH it:

                    from Item i left join fetch i.bids