Problem with session-scoped managed beans in JSF

[daver690]

I find this very strange, either I'm missing something or Hibernate really don't want you to store objects in the session. I'm probably missing something...

It's pretty simple what I have: A couple of pages that resemble a SQL-manager where you can add, remove and edit the content of a few database-tables. Please let me know if I should elaborate on something as I'm trying to keep the words down to make it more readable.

I've got these sessionn-scoped managed-beans that're responsible for the database-tables like this:

@SessionScoped
@ManagedBean
public class TestBean
{
    private Test activeTableItem;
    private List<Test> testList;
    
    public List<Test> listAllTableItems() {
         if(testList.isEmpty)
            testList = getTestSQLData();
         return testList;
    }

   public void addTableItem() { ... }

}

Where Test is a Hibernate mapped class. Then there are more of these classes that set which table-item is currently selected and displays it's foreign-keys and so on like a tree-view.

The first problem was the LazyInitializationException whenever I tried to access the collections of the table-items that were stored in the normal session. It was solved calling the function lock with LockMode.NONE. This worked fine until I wanted to alter the collections of the objects in the session. Then I started getting exceptions about "dirty collections" whenever I tried to modify the collections stored in the session and then access the object a second time. This was solved calling merge on those objects.

Is this really the way you're suppose to do it? Calling merge isn't very nice as it generates additional SELECT-queries in the query-log that aren't necessary, it also removes all non-persistent properties of the Test-objects so I can't for example keep on boolean on those if they're selected.

[Tolls]

How do you expect those objects stored in SessionA to be updated should some of them change in SessionB?
That's what the whole dirty collection problem is about.

Why do you think you need to store all this stuff in the session?
That might be the place to start looking, as that is often (not always) a red flag that something may be not quite right with the architecture.

[daver690]

You mean that the Hibernate-session is session A and the managed-bean session-scope is session B? There's the lock method with the LockeMode.NONE argument that reattaches objects to the Hibernate-session as long as they're not changed. I don't see why there couldn't be a method that completely reattaches an object to the Hibernate-session so it can be used just as before. Similar questions that were asked on the Hibernate-board I think were explained that there would be inconsistencies with the other methods. For example if merge didn't reset all none-persistent properties the get-method would be really strange in that it kept the none-persistent properties from the last time a mapped object was used.

Is this some limitation in Java or just a choice by Hibernate? I came across something about Seam helping you forget about lazy-execeptions, not sure if they go all the way and do the same with dirty-exceptions though... The way I implemented my session-scoped beans were to just store the ID of the active nodes in the tree-view instead of the whole object. Then I just called get whenever I wanted to expand a sub-tree. I don't see why Hibernate couldn't have a "deep" reattach-method doing something similar, or even an option in the properties file to just automatically reattach all mapped-objects to the Hibernate-session when they're used. I mean on some level it's just a database-table and a unique primary key so they should be identifiable where-ever they are.

[Tolls]

I suspect, though I couldn't give you a quote, that it was to avoid unintended overheads with automatically refreshing an object whenever it is touched.
At least with the current setup you have to actually think about whether to actually refresh.
If you set a property to reattach then whenever some barely trained spod touched Hibernate code it would be quite likely they'd be making db calls in the background without actually realising it.
As for a "deep" reattachment method, where would this be and how would it be different to doing a get? It can't be on the POJO as that would mean it was no longer on the POJO.