Hibernate version: 2.1.4

Name and version of the database you are using:mySQL 4.0.20 (myISAM with autocommit)


I have isolated some code in an application that results in some very bad behaviour.
The code is really incorrect, but I need to understand why it is happening.

Essentially what is happening is as follows:

1)Select * from table
2)get java.lang.OutOfMemoryError exception.
3)exception handler does a flush and closes the session.
4)"update table" commands are issued for all rows in the select's record set setting all columns to NULL thus wiping out data!

The sample code is as follows:

private List getProjectList()
{
Session session = null;
try {
session = GetSession();
return session.find("from projects"); // get all

} catch (HibernateException e) {
} catch(Throwable e) {
} finally {
try {
if( session ){
session.flush();
session.close();
)
} catch (Throwable e) {
}
}
return null;
}


public static void main(String[] args)
{

List objects = parent.getProjectList();
List objects1 = parent.getProjectList();
List objects2 = parent.getProjectList();
List objects3 = parent.getProjectList();
}


I call getProjectList() until I get the java.lang.OutOfMemoryError memory. I limit the VM's memory to 5MB to make this happen sooner.

When the session.flush() is called, many updates are issued result in a loss of data!

3)exception handler does a flush and closes the session.


when an exception is catched, discard the session don't flush

>when an exception is catched, discard the session don't flush
Anthony, This I know, that is why I said the code was incorrect.

But my question is:
Why does the flush after OUT OF MEMORY do this (see below) to the data?
The columns where NOT NULL *BEFORE* before the out of memory and flush.... This was totally unexpected.

You will notice the the VERSION column is being incremented.
The sample code *does not* modify any data.

I know how to fix this (i.e don't flush), but I just want to understand what is happening and are there other cases where hibernate might do this?


<from mysql bin log>

update PROJECTS_DB3 set version=590, userName=null, guid=null, event=null, projectName=null, ID_Secondary=null, ID_Production=null, archiveId=null, ID_Additional=null, projectTitle=null, Title_Secondary=null, Title_Production=null, Title_Archive=null, Title_Additional=null, description=null, Description_Secondary=null, Description_Sound=null, Description_Archive=null, Description_Subject=null, Description_Additional=null, comment=null, keywords=null, createDate=null, Date_Due=null, projectStartDate=null, lastModifyTime=null, Date_Completed=null, broadcastDate=null, lastBroadcastDate=null, Date_Repeat=null, NumberRepeats=0, Date_Accessed=null, Date_Archived=null, inciteIdbPath=null, ipcFilePath=null, Location_Tape=null, Location_Geographical=null, Location_Recording=null, Location_Additional=null, destinationProgram=null, destinationChannel=null, projectCreator=null, editor=null, News_Editor=null, Editor_in_Chief=null, Photographer=null, Reporter=null, Presenter=null, Participants=null, Additional_Person=null, journalist=null, assignedTo=null, Language=null, Medium=null, Format_Standards=null, Film_Type=null, Sound_Type=null, VersionInfo=null, Category=null, Addition_Info=null, projectGroup=null, status=null, Project_Priority=null, User_Project_Priority=null, projectOrigin=null, projectEventType='Project', parentProjectGuid=null, archiveStatus=null, archiveTapeId=null, archiveTapeDesc=null where dbId=1 and version=589;

Um??

An OOME excetion occurred while Hibernate was loading data, so it has a bunch of broken objects in the session cache. This is really pretty simple to understand. The state of the session is inconsistent, so of course don't flush it.

If you just follow the well-documented exception-handling algorithm, this cannot happen.