I'´m currently twiddling with an application that has a setup matching the following chat analogy (the actual topic is chess, but this is simpler to explain):
The programmatic setup looks like this: an instance of a chat object with it's messages is shared between PAGE scoped seam component in different sessions. Now, when any session posts a new message, i.e. modifies the chat object, all seam components should be notified of the new message so that the new state can be relayed to the UI on all clients.
I can think of three ways to achieve this:
For the sake of argument assume the number of chat's is large (tens of thousands) and the number of chat users is small (let's say 2-10).
How does each scale performance wise? Do you have any other suggestions how make this with Seam and performing well?
As I see it, (1) would be integrated and clean, but eventually you'd notify tens of thousand of components each time a new chat messages is posted, so it probably won't scale.
(2) would be integrated and only depend on the performance of the JMS provider (which can be exchanged) and would also work in a clustered environment without modifications. I'm not sure about the performance of JMS here, i.e. are a few hundred messages per second a lot or not.
(3) would be fast, because only the required components would be notified and the notification is pure and direct java. However, concurrency / access problems may arise because something cross session / component / thread is done.