[seam-dev] BijectionInterceptor

Pete Muir pmuir at redhat.com
Wed Nov 12 08:49:44 EST 2008


I don't think it's quite that simple when you have concurrent access  
to a component.

Disinjecting/outjecting on the outer-most call of a nested, reentrant  
call is correct if the component is single threaded. However only  
outjecting when a multi-threaded component has no more clients isn't  
very nice. IMO we should disinject when the component has no more  
clients, but outject before any non-reentrant call ends.

Dan, I agree, we do assume that PAGE scoped components are single  
threaded, so we should ensure they are even for server-side state  
saving I think.

On 11 Nov 2008, at 03:28, Dan Allen wrote:

> First, the ordering of the logic in the bijection interceptor is
> correct, as Norman pointed out, because it's absolutely necessary that
> the bijection process wrap the outer-most call to a component.
> Otherwise, the disjection clobbers the temporary state granted to the
> component while the invocation is still proceeding. (This is a point I
> feel I explained pretty well in section 6.4.3 of Seam in Action).
>
> I am pretty certain that the issue being observed here is caused by
> the fact that when using server-side state saving in JSF, page-scoped
> components are not naturally single-threaded. The reason is that the
> page-scoped components are being stored in the session, so two
> simultaneous requests triggered from the same JSF page are going to
> end up seeing the same reference to an existing page-scoped component.
> Seam does not do anything here to prevent those two references from
> being accessed at the same time, giving rise to the possibility of
> concurrent access.
>
> I'm inclined to say that we should simply synchronize page-scoped
> components (or only do it if we can detected server-side state
> saving). When server-side state saving is used, there isn't really
> much of a difference between a session-scoped component and a
> page-scoped component (except that page-scoped components have this
> extremely weakness that they aren't cleaned up reliably because JSF
> doesn't have an API event for UI component tree termination). If we
> don't want to synchronize them by default, then in the docs we need to
> recommend the use of @Synchronized in this case (which, btw, would
> solve all of this guy's problems today).
>
> -Dan
>
> On Mon, Nov 10, 2008 at 8:08 AM, Norman Richards  
> <orb at nostacktrace.com> wrote:
>>
>> On Nov 10, 2008, at 2:03 AM, Shane Bryzak wrote:
>>
>>> In BijectionInterceptor, can anyone remember why we decided to  
>>> perform
>>> outjection only after the last concurrent thread had finished  
>>> invoking the
>>> component?  It's in relation to the following issue:
>>>
>>> https://jira.jboss.org/jira/browse/JBSEAM-3652
>>
>> Well, disinjection follows outjection, and disinjecting after a  
>> nested call
>> would be a disaster.  I don't know how you are seeing concurrent  
>> access to a
>> component.
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>
>
> -- 
> Dan Allen
> Software consultant | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than  
> a week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters.  Please don't hesitate to resend a  
> message if
> you feel that it did not reach my attention.
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev




More information about the seam-dev mailing list