Hi again,
> K.V. Vinay Menon wrote:
>
> Why is the validContexts in the new option D enabled
> EntitySynchronizationInterceptor *NOT* synchrnoized. Will you
> really have a thread safe implementation in that case? I'd sent
> out an implementation of the soft ball cache refresh option
> sometime back [which I never got time to check in!!] and that was
> after finally persuading Marc that we had to synchronise the
> hashset.
As far as I remember Marc was never really conscious of synchronization
in this case, worst case that can happen in a race between looking
for a ctx and adding to/clearing the hashset would be the lookup
failing, thus synchronizing an instance earlier than neccessary.
On the other hand the docs explicitely require synchronization on
HashSet, I don't know what happens in a race between adding and
clearing the set, maybe some internal structure will break. Though
I could look at the implementation, I believe it's better to do
NOT, but stick with the docs, as the implementation might change
without notice!
Also,
>
> a. the hashset is unique anyway why check for presence!
Don't exactly know what you mean, but the HashSet is only used for
commit option D and the class handles A,B,C also.
> b. there will be only one ctx per bean [correct me if i am wrong].
Do you mean one ctx per bean CLASS? No, the ctx has i.e. the transaction
and the security settings attached, so there is one context per
bean INSTANCE, isn't it?
> Also then we'd planned to have it as a separate class that could
> be fit into the inteceptor stack if required.
Was surprised too, but then the additional code is really only
a few lines and the semantics seem far more clear to me with
this solution (i.e. the switch (commitOption) in afterCompletion()).
regards
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
