> That said a lock would be nice sometimes to stop
> the session variables getting clobbered by competing requests. You could
> just have write locks, only allow 1 writer at a time but many readers :)...
> Anyway, this may be completing unrelated to what you were thinking :).
Other software running within the app server also access the session.
For instance, if you have integrated with apache shiro or some other
package that accesses the session outside of the scope of tapestry's
control.
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)
at org.apache.catalina.util.Enumerator.<init>(Enumerator.java:101)
at org.apache.catalina.util.Enumerator.<init>(Enumerator.java:67)
at
org.apache.catalina.session.StandardSession.getAttributeNames(StandardSession.java:1042)
at
org.apache.catalina.session.StandardSessionFacade.getAttributeNames(StandardSessionFacade.java:120)
at
org.apache.tapestry5.internal.services.SessionImpl.getAttributeNames(SessionImpl.java:77)
at
org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:55)
at
org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:62)
at
$PersistentFieldManager_12dec607e56.gatherChanges($PersistentFieldManager_12dec607e56.java)
This looks like it's being run in Tomcat 5.5 because the session
attributes are being stored in a Hashtable. In Tomcat 6 this should be
gone because the session attributes are stores in an
ConcurrentHashMap.
Jetty 7 is using a HashMap so it's probably still going to be a problem there.
Tapestry uses getAttributeNames in two places, which I'd like to
explore removing in the next couple of days.
The other concurrency problem that I'm aware of is because we set the
attribute to null for a micro second to try and trigger
HttpSessionBindingListener. I'm in the process of removing that as
well.
Are there other known concurrency problems with the session?
Josh
On Thu, Jun 23, 2011 at 2:17 AM, Kartweel <r...@exemail.com.au> wrote:
>
> Howard Lewis Ship wrote:
>> The solution I've
>> been thinking of will have some pretty wild performance effects, as
>> requests that share sessions will need to be routed through a single
>> lock object, stored in the session.
>>
>
> I hope it wouldn't hold the lock for the entire request... Sometimes you
> need access to the same session object from multiple requests at the same
> time (eg. if you have a single long running request and another request to
> poll it to get progress). That said a lock would be nice sometimes to stop
> the session variables getting clobbered by competing requests. You could
> just have write locks, only allow 1 writer at a time but many readers :)...
> Anyway, this may be completing unrelated to what you were thinking :).
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Backfixes-for-5-2-6-tp4512055p4516113.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
