11:48 p.m.
I did a thorough evaluation of JBSEAM-3652 and committed both a fix
and a working unit test to show that the disinjection bug has now been
resolved. To sum it up in a short sentence, if a component had at
least three client threads executing it, disinjection would happen
prematurely.
The other important questions that this issue raised is whether
page-scoped components be synchronized by default. I believe the
answer is yes since many people are using server-side state saving in
JSF, making those page-scoped components open to concurrent access. I
have made the change in Compoennt.java. If there is a general
objection, please note that the code will need to be reverted.
Last, but not least, there was a big assumption that was changed that
we need to publicize. Prior to Seam 2.1, it was assumed that bijection
only worked for a single-threaded component. That assumption was
changed in the process of fixing JBSEAM-3295, which reported that
bijection was breaking for application-scoped components. Now we are
basically wrapping bijection around simultaneous invocations of a
component, from the time the component gets a client to the time when
the last client departs. This change raises the question as to whether
we should use outjection after each invocation and only disinjection
when the last client departs. More on that in a separate thread.
-Dan
On Wed, Nov 12, 2008 at 8:49 AM, Pete Muir <pmuir(a)redhat.com> wrote:
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(a)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(a)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(a)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.