Hello,

I'm receiving a StackOverflowError after updating 1 single object, and then calling flush() on the session (2.1.2). The default stack size is in place.

I'm flushing/closing the session in exactly the manner described in the docs under "manually managing JDBC transactions".

Unfortunately, this error has no stack trace whatsoever. I know it is occuring during flush due to my own debug statements before and after the call to flush().

For further investigation, I'd like to turn on a deeper hibernate log level, as I currently only get INFO messages from hibernate. But, under JDK1.4, I've tried:

Logger.getLogger("net.sf.hibernate.impl.SessionImpl").setLevel(Level.ALL);
Logger.getLogger("net.sf.hibernate").setLevel(Level.ALL);
Logger.getLogger("").setLevel(Level.ALL);

and none cause any other messages than INFO level from hibernate.

Does anyone have any idea on where to start looking? -- it's very frustrating not having a stack trace, and I'm not sure why that is. I know hibernate is doing some TRACE level messages during flush() that I'm not seeing in the error logs, and would like to for further pinpointing.

Thanks for your time,

Ryan

1. use log4j
2. check equals/hashCode implementation. Overflow usually occurs on broken implementation.

Thank you, I'm using log4j and now have debug level output.

I've discovered the problem.

During flush(), hibernate is continuously processing the same dirty entity over and over again until a StackOverflowError occurs.

This occurs because a query within validate() of my entity queries the same object/table for any identical entries (a programmatic unique constraint).

Apparently, hibernate doesn't know which to do first. It goes to update the entity, performs validate, and then tries to run the query in validate. Since the query in validate is on the same table, hibernate thinks it needs to flush first. It tries to flush, runs the validate query again, flushes again, etc... Here's where the recursion comes in. Log output from one iteration of the recursive cycle is below.

To prevent this, perhaps hibernate should track when it is in a flush phase, and not allow another flush if already in a flush phase...

On a more practical note, are there any workarounds for this problem? We're trying to keep our entity validation as programmatic as possible.

Thanks,

Ryan

Do not access the session from validate(). The session is in a fragile state during the flush process.

Fair enough. :)

As a work around, what if I set the flush mode to NEVER during validate(), and then back to AUTO at the end of validate()? Still dangerous?

Best regards,

Ryan

yes, still dangerous. Note that you are allowed to open a new session on the same connection and execute queries on that session.