Session.flush(), DB constraints and One Session per Request

rupsch · **Joined:** Mon Nov 06, 2006 12:59 pm **Posts:** 5

Hi all,

I run into a problem and I would like to know how others handle that:

I have two entities (A and B) and A references B. Imagine the DB already contains some Bs and some As reference them. Now I'm doing the follwing.

1.) session.delete(aB) // B Is referenced, the DB won't allow that
2.) session.loadAll(B.class)

Well, the exception (ObjectDeletedException) is thrown at 2.)

For my use case the exception at 1.) would be fine, because I can use the exception to tell the user that the B cannot be deleted. But the exception is thrown at 2.) because of the flush management. In my case the next call like the one in 2.) occurs within the view rendering phase. The exception breaks the rendering with results in not so nice looking views.

Well, the only thing I can do (at least the only one which I could get out of my mind) is to flush the session directly after the delete. This works, but it also means some more flushes than needed in other situations.

I'm using JSF maybe I could place a flush in a phase listener.

how is this handled right?

kind regards

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

If you don't want to flush after every delete, flush periodically. Or flush when you know you've finished all your deletes. Or whenever. But no exception that is caused by an actual DB update (or delete, in this case) will ever be thrown unless there's a flush involved.

Something like this would do what you need:

Code:

int FLUSH_PERIOD = 20;
int i = 0;
for (B aB : colBsToBeDeleted)
{
  session.delete(aB);
  if (++i >= FLUSH_PERIOD)
  {
    session.flush();
    i = 0;
  }
}
session.flush(); // This is only useful if other work might happen between the deletes and the loadAll().

Now you won't get too many flushes.