Hi All -
I have 2 questions related to cache strategy:
1. read-write vs nonstrict-read-write
In a simple test, I run through a loop, reading the same object 100 times. If I have specified read-write cache usage, I always get a "Cached item was locked: " in the log. I can see from the log the session is getting opened and closed as expected - but when should the cached object get unlocked? using nonrestrict-read-write works (as it does not place a lock)
here is a log snippet:
Code:
DEBUG|04:38:58.270|org.springframework.transaction.jta.JtaTransactionManager|Using transaction object [ClientTM[devServe
r+10.0.4.85:7001+dev+t3+]]
DEBUG|04:38:58.270|net.sf.hibernate.impl.SessionImpl|opened session
DEBUG|04:38:58.270|net.sf.hibernate.impl.SessionImpl|loading [com.benefitpoint.cmp.marketing.request.RequestDescription#
79]
DEBUG|04:38:58.270|net.sf.hibernate.impl.SessionImpl|attempting to resolve [com.benefitpoint.cmp.marketing.request.Reque
stDescription#79]
DEBUG|04:38:58.270|net.sf.hibernate.cache.ReadWriteCache|Cache lookup: 79
DEBUG|04:38:58.270|net.sf.hibernate.cache.ReadWriteCache|Cached item was locked: 79
DEBUG|04:38:58.270|net.sf.hibernate.impl.SessionImpl|object not resolved in any cache [com.benefitpoint.cmp.marketing.re
quest.RequestDescription#79]
DEBUG|04:38:58.270|net.sf.hibernate.persister.EntityPersister|Materializing entity: [com.benefitpoint.cmp.marketing.requ
est.RequestDescription#79]
DEBUG|04:38:58.270|net.sf.hibernate.impl.BatcherImpl|about to open: 0 open PreparedStatements, 0 open ResultSets
DEBUG|04:38:58.270|net.sf.hibernate.impl.BatcherImpl|prepared statement get: select requestd0_.REQUEST_ID as REQUEST_ID0
_, requestd0_.DESCRIPTION as DESCRIPT5_0_ from REQUEST requestd0_ where requestd0_.REQUEST_ID=?
DEBUG|04:38:58.270|net.sf.hibernate.impl.BatcherImpl|preparing statement
DEBUG|04:38:58.270|net.sf.hibernate.type.IntegerType|binding '79' to parameter: 1
DEBUG|04:38:58.286|net.sf.hibernate.loader.Loader|processing result set
DEBUG|04:38:58.286|net.sf.hibernate.loader.Loader|result row: 79
DEBUG|04:38:58.286|net.sf.hibernate.loader.Loader|Initializing object from ResultSet: 79
DEBUG|04:38:58.286|net.sf.hibernate.loader.Loader|Hydrating entity: com.benefitpoint.cmp.marketing.request.RequestDescri
ption#79
DEBUG|04:38:58.286|net.sf.hibernate.type.StringType|returning 'this description was updated :Thu Jan 15 16:38:57 GMT-08:
00 2004' as column: DESCRIPT5_0_
DEBUG|04:38:58.286|net.sf.hibernate.loader.Loader|done processing result set (1 rows)
DEBUG|04:38:58.286|net.sf.hibernate.impl.BatcherImpl|done closing: 0 open PreparedStatements, 0 open ResultSets
DEBUG|04:38:58.286|net.sf.hibernate.impl.BatcherImpl|closing statement
DEBUG|04:38:58.286|net.sf.hibernate.loader.Loader|total objects hydrated: 1
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|resolving associations for [com.benefitpoint.cmp.marketing.request.
RequestDescription#79]
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|adding entity to second-level cache [com.benefitpoint.cmp.marketing
.request.RequestDescription#79]
DEBUG|04:38:58.286|net.sf.hibernate.cache.ReadWriteCache|Caching: 79
DEBUG|04:38:58.286|net.sf.hibernate.cache.ReadWriteCache|Item was already cached: 79
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|done materializing entity [com.benefitpoint.cmp.marketing.request.R
equestDescription#79]
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|initializing non-lazy collections
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|flushing session
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|Flushing entities and processing referenced collections
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|Processing unreferenced collections
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|Scheduling collection removes/(re)creates/updates
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
DEBUG|04:38:58.286|net.sf.hibernate.impl.Printer|listing entities:
DEBUG|04:38:58.286|net.sf.hibernate.impl.Printer|com.benefitpoint.cmp.marketing.request.RequestDescription{description=t
his description was updated :Thu Jan 15 16:38:57 GMT-08:00 2004, id=79}
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|executing flush
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|post flush
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|closing session
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|disconnecting session
DEBUG|04:38:58.286|net.sf.hibernate.impl.SessionImpl|transaction completion
2. cacheing lightweight objects I am using the lightweight object pattern, and would obviously like to cache my lightweight objects. I there any provision for auto-evicting the cached superclass instances? It doesn't look like it. I can manually evict the dirty superclass, but would rather not have to pay attention to it. Is there a better approach to handling dirty lightweight/complete objects? I will probably use the composite pattern to handle this properly, but will it be a problem to have a variety of classes who (a) reference the same table and (b) have the same id? there is mention in discussion of the lightweight object pattern that "hibernate cannot load the same database row as 2 different objects". I think I can circumvent the problem by making sure that my updateable components do not share columns (only one class can update any specific column), but I still need to share table and id column.
thanks for any feedback!
tyson
Login
FAQ
Search
