I don't think storing only primary keys and reloading the object from
the database is always the best option:
1) If you need to take a persistent object from a DB and edit it in a
series of "wizard" pages, you actually need to keep the modified object
state in the session. The most direct approach is to store the object
itself in the web session. Of course, you can always clone it, but that
defeats the meaning of "detached" objects whatsoever.
2) You can always use optimistic locking to check for stale data. You
can actually make Hibernate check for the version or timestamp of an
object and tell you if it has changed since the last time the object has
been retrieved. Using only primary keys and clones it gets problematic
doing that check manually.
I'd advocate the use of a more "transparent" approach to this. I think
version checking and object reattaching is something the business logic
/ data access tier should handle "transparently". At least Spring
manages to hide one of the most serious limitations of Hibernate - lazy
collections, but this approach is only halfway there.
(By the way, I'm investigating this problem myself right now, so I also
have a great interest in solving it).
So, basically you'd need to reattach the object (using session.lock() in
Hibernate) in every request. I think it's actually cheaper than
reloading objects based on primary keys, and it also lets you save
modified user data. The problem is - and any suggestions for this - how
would you actually reattach all objects you are using in a consistent
way? One that guarantees that you'll never get a "session closed" error
because you forgot to add a session.lock() somewhere in the 300th page?
Scott Rusells' solution is a pretty interesting one. I still have to
test it out, I guess ;)
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Scott Russell wrote:
On Mon 19 December 2005 13:19, Cosmin Bucur wrote:
It's starting to sound like shaky ground , and problems if i use the
wrong aproach . So basically one approach coculd give me scalability
issues in terms of mixing session data , and the other one is resource
wastefull having to open and close a session for each request . (
alltough in my scenario that wouldn't be such a big issue ) .
The best approach is to use the Spring-supplied hibernate filter, that opens a
session and keeps it open for a single request-response cycle. This approach
ensures that all data access occurs within an already opened session. It
isn't wasteful and it scales well.
The only problem with the approach I described, with the
HibernatePropertyPersistenceStrategySourceImpl (and this applies to any means
of storing loaded objects outside the database) is that the data becomes
stale and is out of sync with more up-to-date transactions. For data that is
fairly static this often isn't a problem, but for highly transactional data
it can cause problems. So in those cases it is better to store only primary
keys, and reload the object from the database as needed.
regards,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
