If an exception in BTM.begin() occurs, the transaction context is incorrect

I'll weigh in on this issue. I do not consider this a bug in BTM. OutOfMemory is a non-recoverable Error.

As explained above, OOME is not recoverable at runtime. Therefore, the right strategy is to avoid its recurring once it happens, by means of configuration, design, or hardware modifications.

http://eyalsch.wordpress.com/2009/06/17/oome/

OOM is an Error not an Exception, and again is not considered recoverable. It is a sign of a misconfigured, or improperly designed application. A properly configured (and designed) server, with no leaks, can run until the Sun (or processor) burns out. An OOM error can occur anywhere at anytime under low memory conditions. An attempt to catch or handle OOM can itself result in an OOM error. Even something as simple as trying to log the exception can itself throw another OOM Error.

An internet search for OutOfMemory and recoverable (or non-recoverable) will backup what I'm saying. Sun's official stance is that OOM is non-recoverable, that's why from Day 1 it has been a sub-class of VirtualMachineError – not Exception.

Sun has added an option to let you take some action, like restart your server, when an OOM occurs:

-XX:OnOutOfMemoryError="<cmd args>;<cmd args>"

See http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

Suggested close.

I'm not sure this problem can be considered a bug in BTM and even in the case it can what it could do to prevent the problem.

This problem can only happen in extreme cases, like for instance when a OOME is thrown in the middle of the begin() call. What should BTM do? Catch Throwable, try to clean up then re-throw the throwable as a SystemException?

OTOH, one could argue and blame this on your code: you provoked the OOME so you should catch it and try to clean up the transactional context.

I'm no trying to tell you this problem is only yours and I won't do anything about it but I'm rather challenging you to explain me what a middleware is supposed to do and can do in such situation.

I probably should have made myself more clear.

I completely agree that the real issue is the OOM, and if BTM wouldn't have get confused, probably some other part of the application would have (although in that particular case, the JVM seems to have recovered)

I just wanted to suggest that BTM could disassociate the recently opened TX when something unexpected occured during initialization.

It's certainly a minor issue or even a wishlist item.

Sure, but how?

There is no way to adequately address this issue. The OOM could have occured any number of placed in BTM and caused similar havoc. If we silently disassociated the transaction from the thread, the app would fail. If we tried to disassociate the transactiion we could encounter another OOM. There are several thousand of lines of code in BTM, and any given line, creating a string, comparing two objects, calling a method, could be hit with an OOM error and the effects on BTM are neither preventable nor recoverable.

BTM was the unlucky victim in the case, but if it were the JDBC driver, log4j, or any other component, somebody else would be looking at a bug, not BTM. I don't mean to be rude or short, but it's like shooting the messenger. BTM was the unfortunate victim of a VM configured with too few resources. Even if we put a try catch in this piece of code, 1) it still could fail with another OOM, and 2) the odds of an OOM hitting that small section of code again instead of any of the thousands of others is almost zero.

Here's an experiment. Configure your VM with 64M of memory, and see how well your application, or any other component in the system deals with the OOM that will result.

It is not recoverable, or preventable, and trying to "fail gracefully" is just passing the OOM problem down the line.

Once again, forget about the OOM. I do not expect any library to fail gracefully in this case, it just happened that I stumbled upon the BTM.begin() section of the code while analysing what happened.

I just want to point out that an exception in that code block(for example, if setActive throws an exception, because the journal got an IOException)) might result in all further transaction calls from that unlucky thread failing with a confusing "transaction timed out"

I'm thinking about something along the lines of

currentTx = createTransaction();

try

catch (Exception e)

Ok, if we're not talking about handling the OOM case but other exceptions, I see your point. The transaction timeout exception is confusing. Essentially, the begin() call needs to be completely atomic. Either it succeeds or fails cleanly. As it is now, if it fails it leaves a side-effect – that of having a (bogus) transaction context on the thread.

What do you think Ludovic? I've attached a patch, which does this in begin():

try {
    currentTx = createTransaction();

    currentTx.getSynchronizationScheduler().add(new ClearContextSynchronization(currentTx), Scheduler.ALWAYS_LAST_POSITION -1);
    currentTx.setActive();
    if (log.isDebugEnabled()) log.debug("begun new transaction at " + currentTx.getResourceManager().getGtrid().extractTimestamp());
}
catch (SystemException se) {
    clearCurrentContext();
    throw se;
}
catch (Exception e) {
    clearCurrentContext();
    throw new BitronixSystemException("exception during transaction begin", e);
}

We have a common agreement, there is nothing we can do about OOME but any other manageable exception can and should be catched.

@Brett: you got the idea right but there are some subtleties you missed, like canceling the TX timeout and the fact that clearCurrentContext leaves some information dangling as it is meant for the suspend case only.

I've basically taken your patch, polished it and committed all that on the trunk. Have a look at revision #360 if you're interested in the gory details.