[seam-dev] BijectionInterceptor

[Dan Allen]

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.