Discussions

EJB programming & troubleshooting: Entity Beans

  1. Entity Beans (18 messages)

    Can anybody give a *clinching* argument in favor of using entity beans against using a session bean and direct JDBC calls (and plain java value objects)? I mean is there a compelling reason or a practical situation, rather, to use a session/entity combo rather than a session/direct JDBC combo?

    Threaded Messages (18)

  2. Entity Beans[ Go to top ]

    Instance synchronization, caching and object pooling.

    What I mean with Instance synchronization?

    Let supose that you have a DAO object that do direct JDBC accces. Two different users request for the same data concurrently. Both of them do calculations, modifiying the DAOs in various ways. At the end, both do store... Something messy can happen, some information will be lost.
    If access to the same data references the same object, this is not a problem.

    Also, most EJB Containers implements some form of caching for the entity beans, and it work very good if you only access your database throught Entity Beans.

    As for pooling, imagine that you do a query that return (let say) 1000 records. With the dao approach you'll create 1000 objects, with pooling you'll create at most the configured maximun.

    All of this can be implemented by yourself, but why bother if the App server programmers do that work already? :)

    m2c
    Rafael
  3. Entity Beans[ Go to top ]

    Let supose that you have a DAO object that do direct JDBC accces. Two different users request for the same data concurrently. Both of them do calculations, modifiying the DAOs in various ways. At the end, both do store... Something messy can happen, some information will be lost.

    If access to the same data references the same object, this is not a problem.

    If you're correctly using transaction isolation options all this problems could be easily sorted out.

    Alex
  4. Entity Beans[ Go to top ]

    If many clients are updating the same entity at the same time, you will definitely run into problems (or a lot of coding) if you use plain JDBC.

    But if you have "read mostly" data (like lists in a combo), the plain JCBC approach will save you a lot of programming work!

    /Tomas
  5. Entity Beans[ Go to top ]

    Is that true even if the JDBC calls are being made from Session Beans? I get a little confused by this. Session beans, as I understand it, are transactional too: I should be able to do a whole bunch of data manipulation with session beans and still have it transactional with ACID properties, no?
  6. Entity Beans[ Go to top ]

    This don't have to be with transactions... Well, perhaps is has to. One of the problems presents when the read and the write operation of a DAO are performed at different times, in different methods of the same Session Bean, under different transactional context. So, if two DAO read the same data, some other process manipulate it and then write it, one of them will have "stale" data, and the new changes will be lost. Even if the read and write operation are made in the same transactional context, two different clients will have different context and the "stale" data problem will happen anyway.

    Let me put this in an example, using a (don't flame me) Web Store. This WebStore use has real-time inventory managment. Let suppose that the ArticleX has 1 piece in inventory. Two clients see it in the page. Then they put it in the shopping cart at the same time. 2 DAOS are created to check the inventory, see that there is one available, and change the data in the inventory. What happens?. BOTH user end up with the ArticleX in their shopping cart, the inventory reflects 0 left. Now, if you even conciliate sales vs inventory, you'll find that 1 more product was sold that the one in the inventory.

    If you say that the Shopping Cart is a Session Bean, well, it changes nothing. This will happen.

    If you use Entity Beans instead of DAOs, this will not happen.

    if you implement a factory of DAOSs, that creates one and only one instance of the same data, you'll be doing the same work done by the container's programmers or JDO programmers.

    This is a real life war story... One of my first mistakes using EJB, as I was also concerned about the performance of Entity Beans (those where EJB 1.1 times)... Thankfuly we weren't in production when we discover it.


    m2c
    Rafael
  7. Entity Beans[ Go to top ]

    Our main issue with Entity EJBs vs JDBC DAOs is performance. We had implemented a solution using entity beans (with a Session EJB facade). We moved to using DAOs (again from the Session bean) and found that the performance improved significantly.

    -John
  8. Entity Beans[ Go to top ]

    Rafael,

    I'm with you up to your second step:

    [[ DAOS are created to check the inventory, see that there is one available, and change the data in the inventory. What happens?. BOTH user end up with the ArticleX in their shopping cart, the inventory reflects 0 left. Now, if you even conciliate sales vs inventory, you'll find that 1 more product was sold that the one in the inventory. ]]

    If the action of (check inventory, see one item is available, and update data) is performed within a single atomic transaction -- even if a DAO instead of an entity bean is used -- surely the error you've described can't happen? Now if you mean "check inventory in one transaction... play with it a bit... then update in a second transaction" I can see how having two DAOs is an issue, but can't I avoid that just by being careful? Maybe I didn't understand what you meant about the two different clients having different transactional contexts.
  9. Entity Beans[ Go to top ]

    The point is that, unless you serialize the access to your data, both DAO reading the last commited value (1), and using them in it's processing . Each one of them has it's own Transactional context.
    Then one DAO commit the new value (0) and ends the transaction, and then the other commit it's own (0).
    This is why i said it was a problem.

    m2c
    Rafael
  10. Entity Beans[ Go to top ]

    Hi,

    The problem here is more to do with transaction isolation and the locking of database columns than entity beans v JDBC.

    In JDBC if you are running an isolation level of READ_COMMITED and you need to change a column like inventory level then you should do a "select xxxxx for update" before you update the column. This will stop anybody else from reading the column until you do a commit or rollback on the transaction.

    In your example the same problem can exist with Entity Beans. For optimizations container like Weblogic 6.x assign an Entity Bean per transaction. For example if two concurrent transaction use say an "Inventory Entity Bean" they each for optimization will get their own copy of the Entity Bean. When the transaction commits it is left to the database to sort out the concurrency issues,

    http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1125109

    I think what I am trying to get across is you must understand how your container operates.
    David
  11. Entity Beans[ Go to top ]

    David,
    You're right. Point taken... I'll put the "Syncronization of instances" out of my bag of entity beans advantages... :(

    ah, life is hard sometimes :)

    Rafael
  12. Entity Beans[ Go to top ]

    Dave,
    I agree with you. When we're talkin about synchronization n all, it's controlled by the Transactional attributes. Which brings us back to square 1. The original question asked in this thread still remains open, is'nt it?
  13. Entity Beans[ Go to top ]

    TX Isolation Levels, rather...
  14. Entity Beans[ Go to top ]

    Well, it sounds like we all can agree that caching and object pooling are advantages. I still have the question, at what point do these become real advantages? At how many transactions-per-minute or whatever does direct JDBC access become less efficient than object caching. The rule of thumb I keep hearing is that object caching only starts being useful for "really big" enterprise applications, but how much is really big?
  15. Entity Beans[ Go to top ]

    James,

    The only way to know that answer is to test... I personally found that (at least under orion/oc4j) CMP entity beans (using custom finders) perform (tps) a lot better that session/plain classes wit JDBC. Also the DB server was less stressed and the memory usage in the app server was fair. But other people found that the opposite is true. So, only testing your configuration you'll know.

    BTW, IIRC calling Entity Beans or plain classes with direct JDBC calls from a session bean will give you transactional support anyway if your JDBC connection allows it. So with a little design you can plug any mechanism you want.

    m2c

    Rafael
  16. Entity Beans[ Go to top ]

    James,

    Caching is not always an advantage and in some cases it's even a performance overhead. Object pooling is not a topic to deal with if you're speaking about DAO JDBC calls. You can easily represent ResultSets in OO form and pool this objects as well if needed.

    Alex
  17. Entity Beans[ Go to top ]

    It sounds to me then that the best solution is to make sure I can rapidly generate my entity model as either CMP beans *or* as direct JDBC calls. Otherwise there's no good way to "test", since converting manually from one to the other would be pretty exhausting work. I understand there are several frameworks (OfBiz's entity model comes to mind, as well as a few code generators) to do this.
  18. Entity Beans[ Go to top ]

    Tomas,

    I agree with you 100% :) The main keypoint in using EJB is knowing when and how to use them.
  19. Entity Beans[ Go to top ]

    Rafael,

    >I agree with you 100% :) The main keypoint in using EJB is knowing when and how to use them.

    Well, that means that the area of usage of entity beans is quite limited. ;)

    Alex