Re: [seam-dev] BijectionInterceptor

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&gt; 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