I have a question about how to approach a certain kind of problem. Let me first explain what I'm doing, and then what the problem is with that.
For the web app I'm creating, a user can, using a web form, edit data which is backed by a model that fetches the persistent object being modified. When the OK button is clicked, the changes are committed, and then show up in the database. So far, so good. While editing a given record called Issue, the user may choose to edit other records that it references (AffectedParty, in this case). To do this, we switch to the new page without performing any commit. When the referenced record is updated, the user returns to the original Issue record. So far, nothing has been committed. All changes will committed when editing is complete for the Issue record. The problem occurs when users open multiple tabs to multiple Issues. In this case, my persistence framework (Hibernate) is using one session for all updates, so a commit to one will affect all the others. This can cause all kinds of complex problems when the user is editing multiple unrelated records at the same time. I would like this application to be able to support working on multiple records at once. One place this can be fixed is in the persistence layer, by associating unrelated records with separate Sessions. However, this can get complicated, fast. Another thing that I might try is to detach the record from Hibernate at the end of each page being rendered, and reattach it at the time of update. Right now, this seems like the most reasonable solution. Is there a standard Wicket solution for this problem? A friend of mine who uses Seam suggested that I check out whether or not Wicket supports conversations, a concept with which I'm only partly familiar (they're like transactions, but can comprise multiple individual transactions...right?). So far, it looks to me like Wicket doesn't directly support this concept, and I'm not even sure how it would help me, anyway. Any suggestions?
