We're updating the issue view to help you get more done. 

Session.load is O(n) when outside a transaction

Description

When retrieving objects from the session-level cache, session.load is O 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 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.

Environment

None

Status

Assignee

Unassigned

Reporter

Matt Sgarlata

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

3.0.5

Priority

Major