[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1311?page=c...
]
Matt Sgarlata commented on HHH-1311:
------------------------------------
I am trying to use Hibernate to render a screen with around 9,000 data points and about
2,000 objects in the session-level cache. JProbe shows that 50.2% of the time it takes
for this screen to render is up by
StatefulPersistenceContext.afterTransactionCompletion(). So, half of request processing
time is used to retrieve items that are already in memory and part of the cache!
The only reason I said it was outside a transaction is because
StatefulPersistenceContext.afterTransactionCompletion() is called as part of
JDBCContext.afterNontrasnactionalQuery(boolean).
Session.load is O(n) when outside a transaction
-----------------------------------------------
Key: HHH-1311
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1311
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.0.5
Reporter: Matt Sgarlata
When retrieving objects from the session-level cache, session.load is O(n) when outside a
transaction, where n = the number of objects currently contained in the session-level
cache. This is because after each object is retrieved Hibernate iterates through all
objects in the session and sets the lock mode to LockMode.NONE. This means reading all
objects from the Hibernate session-level cache while outside a transaction is an O(n^2)
operation instead of an O(n) operation.
If my understanding is correct, all objects in the session should already have that lock
mode unless a different lock mode was specifically requested by the user. Thus iterating
through all objects in the session is not necessary in the vast majority of cases. I
think performance could be improved here by maintaining a cache of the objects in the
session that are currently locked. Then performance of session.load would be O(m) where m
is the number of objects which are currently locked in the session. In the vast majority
of cases this would effectively make session.load a O(1) operation since objects in the
session typically are not locked.
The other solution for me, of course, would be to just wrap all web requests so that I
begin transactions at the start of the request and end transactions at the end of the
request. However, I don't want to do that because transactions require database
resources and I feel it's not necessary to incur that overhead on the read-only
screens in my application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira