So what you are saying is: you want to persist stuff in the database, but you don't want to persist stuff in the database?
Well, you need to choose :-)
Actually, an option is to set your HttpSession and SFSB timeouts much longer than the passivation time, and let the server serialize the intermediate states to disk.
I choose to persist them in the database :-)
My problem is that
- I only want one access/flush to the database once at the end of the conversation
- and I do not want to loose any changes the user did to the entity in the conversation scope because of a conversation timeout.
I already adapted the session and SFSB-life timeouts and made them longer than the conversation timeout.
Hm, can SFSB-passivation be a problem?
A SFSB references an entity of the persistence context and after deserializing a passivated SFSB, the entity would not be connected to the persistence context anymore.
This would mean that I should always take care that a SFSB with entities is never pasivated?