[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1311) Session.load is O(n) when outside a transaction

[Matt Sgarlata (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27472 ] 

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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira