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).
--
[email protected]
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
