Discussions

EJB design: Architecture: Feedback request

  1. Architecture: Feedback request (7 messages)

    We are getting started with designing a web application with a requirement to support upto 150 tps. IBM WebSphere with DB2 backend is the only available option. It is imperative that the transactions be processed synchronously (However suggestions to use JMS, with pointers on how synchronousness can be maintained). It is a large system to be developed hundred percent inhouse.

    I would like to here from our gurus here about...
    1. Use of SLSBs and MDBs.
    2. Entity beans are out. What are the other options?.
    3. Performance is more important that "beauty of design".
    4. Options for persistence (not very keen on ORM based solutions).
    5. Please suggest SP v/s SQL statements.

    6. We are leaning towards...(feel free to thrash it)
    SLSB/MDB (Service Layer)
     L___POJO (Business Objects)
           L____DAO

    7. What is the best practice for passing context related info to POJOs from the Session Beans?

    8. After the .NET vs J2EE PetStore war what have the Java community settled on as an acceptable design for good performance?

    Thanks a bunch.

    ___________________
    Praise the Sun (TM)

    Threaded Messages (7)

  2. Architecture: Feedback request[ Go to top ]

    First, I am no expert on performance, so take that into consideration. I'm no slouch either so I will share some thoughts with you:

    I would suggest doing some research into whether or not you should use EJB. A friend of mine did a performance test for a batch process comparing POJO VO/DAO with using the same VO/DAO with a SLSB. The overhead of the containor (Weblogic I beleive) was around 100 times slower if not slower than that. That could have been a configuration issue or some other nuance, but, in the least, you might want to consider duplicating a similar test to verify these statistics. It shouldn't be that difficult and you might be able to tailor it to your situation.

    One question you need to ask is what are you using the EJB container to do. Are you using 2 phase commit? Connection Pooling? etc. Second, check your JSP container. That might do some of these things for you. E.g I beleive tomcat does connection pooling. Double check whether you really need 2 phase commit. I've never seen a practical situation where it is truly needed. After asking some of these questions you should be able to answer whether or not the overhead of the J2ee server justifies what you get out of it.

    My experience with stored procedures vs. SQL is varied. It has long been a rule of thumb that stored procedures are pre-compiled and therefore faster, but I've been recently told by a DBA that recent versions of oracle this is not (or at least much less) true. Double check this with your DBA.

    As for persistence, I'm an advocate of VO/DAO pattern where the VO models excatly the database table it is modeling as opposed to modeling a OOP domain entity and then dealing with the PITA of mapping that to a relational table. Disconnected recordsets is another good paradigm, but I don't care for using this type of database API. If you need performance then you may not want to model your tables and instead have highly specific SQL. I like the table modeling because you can create tools to generate your VO & DAO objects.

    Hope these ramblings help
  3. Architecture: Feedback request[ Go to top ]

    Like the previous post, I'm not an expert on overall performance, but I too am pretty good. :) That said, ask yourself if there is any way you can break up your transactions into asynchronous units of work. (Does order matter? Does it matter if multiple MDB's pickup your messages, e.g. P-to-P vs. Pub-Sub?) It would scale a lot better than being synchronous. You can use message contexts (transaction contexts) to identify all related elements and re-assemble them when complete. The only recommendation I would make for your MDB's is to put them on a different server than your SLSB's in a cluster. They are threaded and create their own overhead and performance bottlenecks. If you have a significant number of messages which aren't being picked up fast enough you'll run out of memory very quickly.

    Typically, stored procedures are faster than explicit SQL, however, just make sure you use PreparedStatements and Statement caching. As for a persistence means, you could roll your own DAO's but I'd recommend against it unless your project timelines aren't too strict. I know you stated you aren't a fan of ORM tools but you should look at Hibernate to speed development and integration of your data and Object tiers. One thing you could do to simplify things (please excuse my ignorance of DB2, I'm an Oracle guy) is to use Objects in the database rather than relational tables. Anytime you can reduce the translation of Objects to a relational structure you'll save a significant amount of time.

    The only other thing I'd recommend is to make sure you model your activity diagrams and know your transactional requirements. If you find that a significant number of SLSB's and MDB's don't need transactions for their methods, don't use them. It creates a lot of overhead and can leave resources open for a long time until the transaction completes. e.g. Connections, Statements etc. Also, make sure you manage your connections/sessions to the JMS resources effectively. It can take quite a bit of time to lookup and use Destination resources and serializing/de-serializing Objects is very expensive.

    Hope this is helpful.
    Jon
  4. Architecture: Feedback request[ Go to top ]

    You can use message contexts (transaction contexts) to identify all related elements and re-assemble them when complete.

    Could you please elaborate on this or point me in the right direction.
  5. Architecture: Feedback request[ Go to top ]

    Sure, it is too detailed to go into in this forum but you should pickup a copy of "Enterprise Integration Patterns" by Gregory Hohpe and Bobby Woolf. The ISBN number is: 0-321-20068-3. It is a must have book for enterprise development and message driven workflows. In the book review the resequencer and splitter patterns.

    Hope this helps.

    Jon
  6. entity EJBs[ Go to top ]

    Entity beans are out. What are the other options?.

    1) this is very common opinion on the TSS ... :)

    2) SUN's Entity EJB 2.1 is implemented by JDO; Oracle's one by TopLink; JDO and TopLink are quite good technologies

    3) BEA Entity EJB 2.1 are faster or at least have similar speed as the Hibernate (published on the TSS)

    IMO EJB 2.1 has only 1 problem and it is the rich OO domain model, what is not a big problem for me, because I do not stress the relation Oracle by rich OO model anyway
  7. entity EJBs[ Go to top ]

    A good EJB container will have entity beans performing just as fast as any other persistence layer you can find. BEA WebLogic is a fine example.

    The catch with entity beans is that in order to achieve such performance you will have to use all sorts of proprietary extensions to the entity beans themselves, therefore resulting in a less portable project. It is up to you.
  8. entity EJBs[ Go to top ]

    You know Andre, if you want to look COOL you have criticize the EJBs. There is no other way ... :)))))))))