Inter-session events?

[nickarls]

Is there any (lighter than JMS) way of doing cross-session events?

I have the situation where I have a conversation-scoped entityquery which refreshes automagically on afterTransactionSuccess, but I would need them to refresh even when another user makes a modification that triggers the event. I could use an application scoped query but I have the feeling that my entityConverters wouldn't like that...

[yocasper]

I don't know if this is what you're looking for... You could observe and store the event in an application scoped component and then use a page action (which is executed in every session) to check if there are any new events. If so, just fire the event again.

[walterjwhite]

There is always a solution to a problem.

I do a similar thing, for instance I notify a user if someone attempted to hijack their session based on their remote address (if they're behind NAT, this doesn't work) or if they're browser headers significantly change (user agent), then I raise a flag.  That flag is fired in the attackers session/request and sets a message in an application-scoped component.  Then when the victim makes the next request, that component is pulled for any notifications for that particular user/session.

Depending on what you need, you will have a different solution.  This works well for simple notifications that don't need to be guaranteed.  Since there is no guarantee the user will ever make another request within the session timeout.

Thinking about the problem somewhat differently.  If you have 2 stateful session components and you want those components to talk, how do you do that?  I don't have any use cases that really come to mind (the example above works with the implementation I mentioned and this might be heavier).  I'm thinking that you can simply observe an event in that component and then only process it if it matches the parameter:

@In
private Session session;

@Observer("event")
public void onEvent(final String sessionId, final Event event)
{
  if(session.getId().equals(sessionId))
  {
    ...
  }
}

How does that look?

Walter

[nickarls]

Could be worth a try, thanks. The case I have is I have common data bound by an EntityQuery, so If person A inserts a row, person B should see it. I use ICEfaces session rendering so the updates are pushed, once the clients can react to the fact that the EQ needs to refresh/redraw.

The simple solution to this would of course be to use an appscoped EQ but that leads to all sorts of value not valid and entity is detached when dealing with entityconverters and entities without equals/hashcode (stuff that works nice within a LRC/single EM)

The stuff would need to appear in realtime so (page)action based polling is something I'd like to avoid. So we're probably talking about some sort of event-propagation here. I need to signal an app-scoped component (the only common point of data access to all clients) and have events distributed to all clients (the transaction-success event that triggers the EQ refresh). But what would be the method for distributing the event to the clients so that it runs in their "invocation context"?

I'm not convinced that the observer sees the event in your example because if I trigger an event, my observer method is called, not yours so there is no point checking for match on session id, it won't hit anyway(?)

[swd847]

I would use a phase listener that polls the app scoped component at the start of each request.

[nickarls]

Yep, but again, that's active polling, stuff isn't automagically appearing while the user is idling.

Hmm. Wonder if I could store the conversation-scoped entitymanager and the conversation-scoped entityquery of the client in some collection in an application-scoped component and iterate over them and refresh them with their own entitymanagers. Sounds a bit like a hack, though.

[nickarls]

OTOH, since I have the ICEfaces slow-polling stuff, perhaps I could just have an application-scoped bean + an int field which I increment to signal a change. Then the clients have a hidden field pointing there. Then somewhere in the getter or valuechangelistener the event that refreshes the entityquery on the client is fired. Hmmm, gotta try it.