8 Replies Latest reply on Jan 14, 2005 8:10 AM by aloubyansky

    ejbFinders are not even consistent with themselves?

      If I am running in READ_COMMITTED isolation, then the only guarantee that I have is that each individual SQL query I issue will run over a consistent view of the database, with no outstanding work to be committed. Changes may be committed between queries.

      So I could sum up the gross and nett weight on a load of order lines with the statement

      SELECT SUM(nett_weight), SUM(gross_weight) FROM order_lines WHERE....

      Now if I use an ejb finder to retrieve the instances

      SELECT OBJECT(o) from OrderLine WHERE ...

      One query is used to get the list of ids.

      Now as I read through the returned collection and load the state of each object, a new query is issued to the database to load the state of the object.

      The problem is that as I read through the returned order lines, another transaction may have committed changes on the lines I haven't read yet (still satisfying the conditions of read committed), and I am working with inconstent data.

      If I was working with Hibernate or manual JDBC, I at least have the option to do everything in one query. With the fundamental way that ejb finders work, I cannot do that, and run far greater risk of working on inconsistent data.

      Is this analysis correct?

        • 1. Re: ejbFinders are not even consistent with themselves?
          hariv

          You can probably use the read-ahead strategry where the container will load a list of columns you specify in the group along with your id in one query. The extra data is stored in a seprate cache and your entity bean will be populated with the cached data during ejbLoad.

          • 2. Re: ejbFinders are not even consistent with themselves?

            Two problems:

            1) It only works when talking about data from one entity. What if my query went across several entities / tables, retrieving some attributes from each? Can't use a ejbFinder. And because ejbSelect statements can only return one result per row, they don't work either.

            2) this declarative approach at build time forces the read-ahead strategy on all users of the bean, whether their transactions require it or not. Making it impossible to allow optimal performance per transaction.

            The problem is that ejb querying is an insufficient API. At the moment I really feel this is broken by design, and that another solution such as Hibernate has to be used.

            Please point out why I'm wrong. I would love not to be forced to convert all the entity bean code we have developed over the past year to Hibernate.

            • 3. Re: ejbFinders are not even consistent with themselves?

              And a third problem:

              3) I have to find out how to do this in every app server. We are an ISV and want to remain app-server independent. Because this is another of those glaring omissions from the EJB 2.x spec, it is solved differently, if solved at all, in each app server.

              • 4. Re: ejbFinders are not even consistent with themselves?
                aloubyansky

                You could use left-join read-ahead, see wiki.
                The spec does not define loading strategy. So it's a vendor-specific thing.

                • 5. Re: ejbFinders are not even consistent with themselves?

                  This is the same answer as provided by HariV(?)

                  What about the questions I raised in response to that (1 and 2, disregard 3).

                  • 6. Re: ejbFinders are not even consistent with themselves?
                    aloubyansky

                    1) Read about left-join read-head.
                    2) no other way but define a finder for a use-case.

                    • 7. Re: ejbFinders are not even consistent with themselves?

                      Thanks for the response.

                      1) looks like a good solution.
                      2) here's the problem with entity beans. I have to know all my business cases in advance, declare them in the descriptors, and provide a finder for each. Everything is completely entity-centric, instead of usage (transaction) centric.

                      I get the following problems:
                      1) I could end up with lots of finders with incredibly long names so that the client knows what they do. Complicate my API for everyone to look at just for corner-case transactions.
                      2) The developer, working on a particular piece of logic, has to go to the entity, add a new finder and rebuild. Poor productivity.
                      3) I must verify that I can do this with other application servers
                      4) If I find that it can be done, attempt to put automatic processes in place in my build system to build the config for each

                      All when I just wanted to say "select these 10 fields from these 2 joined entities" in one transaction.

                      I think JBoss generally provides very good solutions within the constraints of the entity bean paradigm. More and more however, I find that the paradigm is inflexible and bars portability.

                      That is in no way intended to be a rant at JBoss. I will continue to use, recommend and deploy it, and I always genuinely appreciate the prompt and accurate advice I get from key figures on these forums, something I can never get from other vendors.

                      But I think that as an ISV who must remain portable, I must look to another persistence solution.

                      • 8. Re: ejbFinders are not even consistent with themselves?
                        aloubyansky

                        That's why we recommend Hibernate/EJB3.