I am not a specialist but here are my two cents. I assume that your webservice runs on a Java EE application server.

• all the writes to the DB should come from your application server so you should be able to generate events in your code every time you write to the DB
• instead of webservice which are best for queries from the client, you could use either websockets or a message queue (typically a JMS queue)

Although having the clients write to the DB directly may seem appealing at first (it’s easier to understand) it can quickly become a mess. For example, making changes to your DB going forward may require upgrading all clients.

It sounds like you are looking to implement push notifications from your back-end service to each front-end client.

Two options come to mind:

1. WebSockets will allow your clients to maintain a persistent two-way communication channel with the server. Updates on the client can be sent along the persistent channel, and when the web-server receives a change to the data store, it can propagate it out to each connected client. Using this, each client will probably (more on this later) have the most updated data whenever it wants to make a change to it

2. HTTP Long Poll is an older method (that works quite well) that utilizes HTTP with long timeouts to accomplish something similar to push updates. Each client opens a HTTP request for some resource and has a long timeout (say, 2 minutes for example). When something changes, the server will respond with the new data, otherwise, it will wait for the full 2 minutes before sending a 304 NOT MODIFIED response to the server. In this way, the client can get notifications pretty quickly, but without constantly polling.

Both of these ideas can be read up on here: https://en.wikipedia.org/wiki/Push_technology#HTTP_server_push

Both of these options suffer from the possibility that two clients will want to make updates at the same time, and one my overwrite the other. In this way it is easy for your data-store to become out of sync or have logical inconsistencies in it. If you would like to avoid this, as pjc50 mentioned, you may want to consider using a distributed database.

For those who will think it is useful, here is some pseudo-code for long-polling:

long-poll client & server pseudo-code

/**
 * Handles long-poll request for one client and sends updated
 * content to the client when it changes, or a 304 NOT MODIFIED
 * response if it doesn't change within the timeout period
 */

handleClientRequest(HTTRequest clientRequest) {
    String uri = clientRequest.getURI();
    int timeout = clientRequest.getTimeout();

    /* Wait for the resource to change. You should use
     * a more sophisticated waiting scheme, like semaphores,
     * java monitors, or any number of thread synchronization
     * techniques
     */
    while ((resource hasnt changed) && (total wait time < timeout))
        sleep(timeout / 100)

    if (resource did change)
        send new content
    else
        send HTTP 304 NOT MODIFIED response
}

/**
 * Continually sends long-poll requests to the server,
 * and updates data whenever it changes
 */
clientLongPoll(uri) {
    int timeout = 120 // seconds

    while (true) {
        HttpRequest request = new Request(uri);
        request.setTimeout(timeout);

        /* this will hang until the server responds, up to 2 minutes */
        HttpResponse response = request.send()  
        if (resposne.contentChanged() == true)
            update local data store
    }
}

Web socket libraries usually rely on an event-based scheme (onConnected(), onNewMessage(), onDisconnected(), etc…), but each library is different. The basic idea is that whenever a client starts up, it should contact the server to initiate a WebSockets connection, and from there, each can send messages back and forth whenever their local data changes.