Its not quite that simple, again due to how we recurse. This would
need to be a "stack" stored on a ThreadLocal. Depends what you want to
store in here I guess, but like I said we already have "context
specific caches" and it would be good to consolidate all that
information into one place. What I mean by the current "context
specific caches" is the "extra" information passed to many of the
listeners. Take merging for example:
interface MergeEventListener {
public void onMerge(MergeEvent event);
public void onMerge(MergeEvent event, Map copiedAlready);
}
'copiedAlready' is a context specific cache. It tracks entity
reference replacements. Many listeners have similar concept.
Your proposal would certainly clean up those APIs.
On Wed 10 Oct 2012 03:01:30 AM CDT, Emmanuel Bernard wrote:
On Wed 2012-10-10 9:26, Emmanuel Bernard wrote:
> Would using a service that store cache data structures by session work? I am thinking
out loud here trying to push the cache idea before discarding it. That would require a
weak-key concurrent map. The one I know is the one Jason wrote as a proposal for SE. I.
Cannot remember where we use it but it must be in Search or in Validator.
Actually that is simpler than that. Because the session cannot be used
in more than one thread, only one call stack is active per session. We
can keep the cache per session and lear it before every top level public method
of session (ie persist, flush, merge etc).
--
steve(a)hibernate.org
http://hibernate.org