Nope, what happens is that when the transaction is completed, we remove =
the cached representation of the object and the very next transaction =
that needs the same instance will be forced to load it from the database =
and recache it.
*While* we are editing it, other transactions are forced to go to the =
database if they want to view it (the definition of "while" is slightly =
complicated ... something to do with transaction start times and such). =
Essentially we are using the multi-version concurrency model (NOT a =
lock-based model). Search back thru' the mailing list archives for a =
full discussion of how it works but all you really need to know is:
* repeatable read transaction isolation is maintained (if that is =
underlying isolation level of the JDBC connection)
* no thread *ever* blocks or returns an exception on attempting to =
access the cache. A thread might block when it attempts to hit the =
database
This model is expected to exhibit very high thread-level scalability.
----- Original Message -----=20
From: Joost van de Wijgerd=20
To: hibernate list=20
Sent: Friday, October 11, 2002 5:38 PM
Subject: [Hibernate] Factory level caching and in-memory updating
Hi,
I have the following situation: Im using factory level caching to =
cache all my object instances since
most of the time users will be only reading the information. Every =
once in a while though, information
will be edited. Editing is a stepwise process which at the end of the =
steps will have to be comitted (by
the user!) or not. I am wondering: If the process changes the contents =
of an object in memory, I assume
it will be changed in the cache and so all browsing users will see =
this information? What is the right way
to do this with Hibernate? I assume some kind of locking, but I am not =
sure how this works with the cache.
maybe somebody can shed some light on this issue.
thanx
Joost
--
Joost van de Wijgerd
JTeam B.V. www.jteam.nl
jo...@jt...
+31(0)6 24 111 401
"A good developer knows development is more than programming.
A great developer knows development is more than development."
-- Scott Ambler
|
