Concurrent Programming with Container

Hello,

after some time of usinge Vaadin I now run into some implementation/program design/understanding problems. I just want to know if a best practice excists, respectively, how things are handled in Vaadin.

Let us say we have the AddressBook Example, and the a PersonContainer as in the example. User A changes something in a Person’s Property and saves the Person. What is the best(or common) way that user B sees these changes (Which interfaces must be implemented, which events are called? Is that even possible cross application?)

Regards Niklas

If the collection of data you are playing with is moderately sized then use a data structure shared in memory, else use a real database. Each application will then build a container around it – you cannot share the container between applications. If using a persistence engine (e.g. JPA) you will probably want to detach the instances as soon as you get the objects, and explicitly merge them prior to writing.

For notification, use an event bus (see the BlackBoard add-on for example, or some well-known EventBus library, this is tricky stuff) so that the various applications (each is an http session) are notified of changes to your container – don’t extend the Vaadin notifications, you’d be working at the wrong abstraction level. Remember that it is the notifying application that is running, so when you update the listening application’s UI objects, you are in effect working in the background – you will need to fork a thread so you don’t block the original users’ UI, and you will need to synchronize on the target application so you don’t have “out of sync” errors.

An event bus works well when you have a moderate number of users interested in a given event and you are able to multithread the broadcast. But if you have hundreds of users that are all tracking the same item, and want to see the changes (say the stock price for RIM and Apple) it is perhaps more efficient to have a client-pull – let each client poll frequently, cache the frequent data. See things like hazelcast.com for multi-node scaleability and distributed caching.

thank you for your long answer. it helps very well in understanding. now i have to translate that to code.