Use a timer to redo queries and / or connection and / or your JTables;

Something like

import javax.swing.Timer;
// (...)

Timer timer = new Timer(0, new ActionListener() {

   @Override
   public void actionRefresh(ActionEvent e) {
      updateRecords();
   }
});

timer.setDelay(30000); // refresh a cada 30 segundos
timer.start();

There are several ways to resolve synchronization between multiple clients in a data source. Some are simple and inefficient, others are efficient yet complex. I'll cite two approaches.

Periodic verification

Mark's answer uses this technique. In it, you create a Timer or some object that runs at regular intervals, where you then update the values from the server.

This is the simplest and least efficient method. If there is too much data, the system will get blocked frequently and irritate the user. Also, it will transfer lots of data unnecessarily if they have not changed between one run and another. This technique is impractical if you need real-time updates.

One way to improve it a bit would be to run a lighter query to see if there was any change. For example:

• If only the number of records imports, you can make a count of the table and only update the values if the result is different from the previous
• Add a field with date of creation or modification of the records and see only the records added after the last update of the table
• Make pagination, just bring the last n records.

Default Observer

A more complex scenario would be the implementation of a mechanism for listening for modifications.

For this, no external system should modify the database directly. The Android app and other clients should always update the base via some API, such as a RESTful Web Service.

This Web Service would allow customers to connect to it and receive event updates. So, whenever a record was added, all listeners or observers would be notified.

The desktop application, when started, would connect remotely to the service and keep that connection open by listening for events.

Note that this makes the application much more complex as it needs to deal with several different implementations, a public REST API, and possible client / server communication failures.

However, it may be the only way out of a more complex scenario, such as where there is need for instant updates or too many clients that would overload the database with queries.

Be careful not to break user flow (usability)

Be careful when updating the screen automatically. If the user is looking at the records, or even editing one of them, and everything disappears from the screen, this will have negative consequences for someone.

If the data is changeable, an idea is to notify the user that there are updates, but only update the table when it clicks on any button or link.

If the data is immutable, there is not much problem. Just try to keep the focus of the user on the same record between the updates. For example, if the user selected the record written "banana" and suddenly the focus is on "orange", it will get lost every time the screen changes.

Look at the initial screen here of Stack Overflow as the questions are updated to get an idea about it.