2:03 a.m.
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
7:08 a.m.
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.
10:28 a.m.
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.
7:49 a.m.
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
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.
6349
days inactive
6353
days old
4 comments
4 participants
participants (4)
-
Dan Allen -
Norman Richards -
Pete Muir -
Shane Bryzak