We are doing a quick-and-dirty port of an ASP site to JSP/EJB, and simply
replacing the stored procedure calls with stateless session EJB methods
one-to-one. (This is phase I of a more comprehensive redesign effort, btw).
Anyway, some of the stored procs start a transaction, then call other stored
procs. But those other stored procs are also called directly by the client
code. Since each of these stored procs is converted to a bean method, when
we port, it will be bean methods calling other bean methods, and potentially
other beans, too. If the latter is the case, then we have a potential
problem with a bean starting a transaction (turning off autocommit) and then
calling another bean. (We are using the TXDataSource pool driver)
If it were not for the possibility of a transaction involving multiple
beans, I would say the easiest solution is to put all of the JDBC code into
private methods that accept a Connection argument, and so they participate
or not participate in a transaction based on how the Connection was set up.
Then each public (published) bean method would get the connection,
setting/unsetting autocommit, and call the private methods it needs. This
would also make the code much cleaner, since each published method would
just be a summary of the db operations to be performed and not all the jdbc
ugliness...
Anyway, in order to do this, I considered created some classes that consist
of static methods, which could be called by any of the beans, instead of
private methods in each bean. That way a particular db operation is
available to any bean without having to make the remote call to the bean
that hosts it, and the transactional logic can all be kept in the beans
themselves.
Is this a bad idea in any way? The only thing I'm not 100% sure of is
whether these "static classes" would become a bottleneck, not being that
familiar with the internals of the JVM. These classes would have no instance
or class variables, just static methods with private variables, so they
would not need to be synchronized.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
