Hi all,
in my application some clients need to insert/modify
data of 5 DB tables, while other clients (the majority)
need only to select and display the same data.

Can I use a session facade pattern (a Stateful Session
Bean + 5 Entity Beans) to implement the insert/modify
operations, and a Stateless Session Bean, with
direct use of JDBC, for the select operations ?

If this mixed architecture is usable, the Stateless
Session Bean need to perform its selects inside
a transaction ?
And what's better: declarative or programmatic transaction ?.

Many thanks in advance
Moreno

Hi Moreno,

  I would suggest Stateless Session Beans (you don't need Statefull Session Beans for the operations you described, unless you want to remenber the previous operation of a user) with CMP(JDO, Hibernate) for insert/update and Stateless Session Beans with JDBC(JDO, Hibernate) for reading. The JBDC for Reading is a great pattern to use for reading operations. You can read about this in Floyd Marinescu's book "EBJ Design Patterns" (available for download at http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloadbook.jsp).

  Cheers.

Hi Sergiu and Tomas,
I'll try with JDBC for Read operations and Entity Beans
for write ones.

I think I need to use a Stateful Session Bean with Entities
because there's a dialogue between client and session.
The client calls different session bean's methods and
the session store client informations during this calls.

Thanks again
Moreno

The "JBDC for Reading" is a workarround for an Entity EJB design flaw and is
certenly not a pattern.

There is a big problem with "JBDC for Reading Pattern" is that it introduces dependency between client code and the DB, and thus negates one of the main benefits of Entity EJBs. If the DB columns change (column added, dropped, renamed, column type changed...) you have to change your entity bean and deployment descriptors as well as all your code that use "JBDC for Reading Pattern"

If you have only 5 DB tables and not too many records in these tables go for entity EJBs in both cases (reading AND writing).
Otherwise use JDBC or JDO or Hibernate for the data access in both cases. Having mixed data access/manipulation strategy is not very wise decision.

>> You can read about this in Floyd Marinescu's book "EBJ Design Patterns" (available for download at http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloadbook.jsp).

Much better patterns book is Martin Fowler's Patterns of Enterprise Application Architecture where he describes patters applicable not only to J2EE but for any enterprise application platform today, either it is J2EE, .NET, CORBA/C++ or even COBOL/DCE. Knowing how to solve problems independently of application development platform will help you to solve it better on you particular platform.

Mileta

Hi!

If you go fore Stateless Session Beans or Entity Beans for read/write clients, the solution looks good. (I don't see the reason for using Stateful Session Beans.)

Using different part of the application for read/write and read-only operation is not only a good idea. In many cases it is needed. You can also take a look at http://java.sun.com/blueprints/patterns/FastLaneReader.html to find that this idea is recommended by Sun.

/Tomas

Hi Monero,

There is no need for a stateful session bean, since there is no need for the cients earlier processes to be remembered here.

Jineesh