How about like this scenario?

Client Request -------------> Begin Transaction
                                        |--- Process 1
                                                |--- Stored procedure 1
                                                |--- Stored procedure 2
                                                |--- Stored procedure 3
                                        |--- Process 2
                                                |--- Stored procedure 4
                                                |--- Stored procedure 5
                                        |--- Process 3
                                                |--- Stored procedure 6
                                        |
                                       End Transaction

how does thi gonna looks like interns of EJB design? Process 1, 2, and 3 are
meant to be reusable, as well as stored procedures maybe reused in other
processes. My intention is to execute 3 process in one transaction where all
stored procedure must be completedm within the transaction, otherwise all
must rollback.

Thanks

Neo
----- Original Message -----
From: <david.lorde@f...>
To: "Java 2 Enterprise Edition" <j2ee@p...>
Sent: Friday, April 12, 2002 4:18 PM
Subject: [j2ee] Re: Session or Entity?


> There is no 'right' or 'wrong' way to manage these things. Entity beans
> provide an object interface to your persistent data (usually in a
> database). The recommended J2EE model architecture suggests that entity
> beans are wrapped in session beans which provide a business-logic layer
> for application-specific code to use.
>
> In some circumstances, especially where there are many complex queries to
> satisfy, session beans may also be used to query a database directly via
> JDBC (e.g. a complex SQL query) rather than attempt to process the data
> returned from multiple entity beans in a session bean.
>
> It has been suggested that the overhead of using entity beans means that
> they should be restriced to inserts, updates, and small, simple (trivial)
> queries. However, a good server implementation will cache entity beans,
> and actual performance on multiple similar queries via entity beans may
> exceed that of direct JDBC access because of this cacheing.
>
> In my experience, where queries will involve complex selections across
> many tables, or where the entity bean model in use doesn't lend itself
> well to satisfying a particular query (i.e. a JDBC SQL query can simply
> achieve what will otherwise require considerable code involving entity
> beans) it's easier and quicker to use JDBC direct from a session bean.
>
> Dave
>



_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com