Transaction propagation from Oracle 8i or 9i to OC4J V2?

Question

We have a very large Oracle 8i (8.1.6)-based application that uses PL/SQL exclusively for business logic; there are a few hundred user packages. We are considering a gradual introduction of EJB's into the mix, most likely via OC4J V2 when it is released.
Issue:
Because of the significant legacy of PL/SQL, it will be necessary to NOT ONLY be able to invoke PL/SQL and SQL from the EJB residing in the app server in a global transaction, BUT ALSO go the other direction: have a PL/SQL proc/function call out to an EJB in the app server. I theorize we can do this by setting up Java Stored Procedures that act as a facade for invoking EJB methods.
Scenario:
Oracle Forms web client invokes PL/SQL stored procedure, which invokes Java stored procedure, which looks up and invokes an EJB (EJB spec 2.0) in the app server, which invokes PL/SQL stored procedure or just plain SQL via JDBC.
Forms client -> PL/SQL SP -> Java SP -> EJB (on separate app server) -> PL/SQL or SQL.
Questions:
1) Assuming using OC4J V2 as the app server and Oracle 8.1.6 as database at both ends, will a transaction begun with the client (e.g. Forms 6i) propagate to all tiers of the call chain above? If not, why?
2) If it does work, is there anything special that must be coded in the Java stored proc, e.g. anything special usage of JTA?
3) Will it work the same in Oracle 8.1.6 and Oracle 9i?
4) Are there any problems using J2EE 1.3 API's from within Java stored procedures, given that Oracle 8i and 9i have backlevel built-in support for many of these features? In particular, I understand JServer has EJB 1.1 builtin, but what if I want to use an EJB 2.0 running in an external app server?
5) Are there any JTA incompatibilities between 8i/9i and J2EE 1.3 implementations (e.g. OC4J V2), particularly that would hamper this scenario?
6) If all is good so far, could I expect to replace OC4J with another J2EE 1.3 compliant app server (e.g. WebLogic or WebSphere) and still have same results?
7) Is it necessary to setup 2-phase commit in Oracle if the both the client-invoked and EJB-invoked databases in the above example are the same Oracle instance?

Answer 1

Hi Scott,
Answers appear below your questions...
Questions:
1) Assuming using OC4J V2 as the app server and Oracle 8.1.6 as database at both ends, will a transaction begun with the client (e.g. Forms 6i) propagate to all tiers of the call chain above? If not, why?Client side transactions are not supported (as far as I know), so
the answer is "no" and the reason is "not supported".
2) If it does work, is there anything special that must be coded in the Java stored proc, e.g. anything special usage of JTA?Irrelevant, since client-side transactions aren't supported.
3) Will it work the same in Oracle 8.1.6 and Oracle 9i?Yes, since neither 8i or 9i support client-side transactions.
Besides (again, as far as I know), both 8i and 9i both have the
same embedded JVM.
4) Are there any problems using J2EE 1.3 API's from within Java stored procedures, given that Oracle 8i and 9i have backlevel built-in support for many of these features? In particular, I understand JServer has EJB 1.1 builtin, but what if I want to use an EJB 2.0 running in an external app server? The database (8i and 9i) EJB container is not the same as OC4J. In
fact (as far as I know), Oracle recommends NOT using the embedded
container and using OC4J only. This means that in order for a java
stored procedure to lookup an OC4J EJB, you need to load the OC4J
JAR files into the database (via the "loadjava" tool). I haven't
tried it, but someone else posted to the forum saying he would try
it -- but I don't know how his experiment turned out. However, as
a workaround, you can use RMI in a java stored procedure. I have
successfully done this.
5) Are there any JTA incompatibilities between 8i/9i and J2EE 1.3 implementations (e.g. OC4J V2), particularly that would hamper this scenario?I don't know how to answer this question, sorry.
6) If all is good so far, could I expect to replace OC4J with another J2EE 1.3 compliant app server (e.g. WebLogic or WebSphere) and still have same results?Theoretically, J2EE compliant applications should be able to be
deployed and executed in any J2EE compliant application server.
However, another person in this forum had some difficulties in
migrating a ready built application from weblogic (I believe) to
OC4J. I think the problems were due to the application server
specific configuration differences (but I'm not sure).
7) Is it necessary to setup 2-phase commit in Oracle if the both the client-invoked and EJB-invoked databases in the above example are the same Oracle instance? I'm not sure about the status of two-phase commit support in OC4J.
Again, there is a (still unresolved, I think) thread in this forum
about some buggy commit behavious for CMP entity beans. However,
if you're asking this in the context of your scenarion (involving
client-side transactions), then it is moot, since, as I said earlier,
client side transactions are unsupported.
Hope this will help you,
Avi.