Problem with CMT Stateless Session Bean setRollbackOnly() not working

All,

I've been reading a ton of posts on this subject and have not found an
answer.

I am using WebLogic 8.1.  I have an application with a bean whose
deployment descriptor indicates that transactions are to be
container-managed.  The deployment descriptor also indicates which
methods use REQUIRED for their <trans-attribute>.  I then have a small
piece of code that modifies a database, purposely throws an exception,
catches the exception, and then calls setRollbackOnly().
Unfortunately, even though setRollbackOnly is being called, the changes
to the database are being committed.  I don't know why.

Here's an example of the code:

public String methodUsingRequiredAttribute() {

Class.forName("oracle.jdbc.driver.OracleDriver");
Connection oConn = DriverManager.getConnection("oracleThisDriver",
"aUser", "aPassword");
// .. create a statement .. update a table in the database
try {
throw new Exception("testing rollback");
}
catch(Exception e) {
getContext().setRollbackOnly();
System.out.println("setRollbackOnly didn't throw error");
}
}

When I run this code, it prints out that setRollbackOnly didn't throw
an error - but the database remains changed.  Any thoughts on what I'm
doing wrong?  I know that ideally I'd get a connection from a
datasource - and I'm not doing that here - but I don't see how that
changes things.

Is it possible there's something wrong with the database driver that
I'm using (the oracle thin driver)?  Or my version of WebLogic 8.1?

I'm at a loss...

Any light you can shed would be appreciated.

-john

I want to make sure I understand your answer.  Are you saying that the
way I currently obtain my connection is "bypassing" the container so
that the call to setRollbackOnly isn't working?  If that's the case,
then I'm happy to change how I obtain my connection.

How do I do that?  What is the correct way to obtain a connection so
that the container-managed transaction model isn't broken?

-john

The WL doc indicates that calling setRollbackOnly should cause a CMP transac
tion to rollback, but experience told me that you need to throw the exceptio
n to trigger the rollback. (see below).

- Daniel

try {
  throw new Exception("testing rollback");
}
catch(Exception e) {
  getContext().setRollbackOnly();
  System.out.println("setRollbackOnly didn't throw error");
  throw e;  // needed to trigger the rollback.
}