There are a couple of ways to handle this. The way you suggested about the checking every 2 seconds is known as "polling" or a "pull" system, where the client asks the server what has changed. As you said, this can lead to extra network traffic. Another simple way to accomplish this is using the Observer pattern (a "push" system). The client tells the server that it wants to be notified whenever something changes. One example can be found here. http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html.
I'm not convinced that there's a really a problem with client pull. Sure, it's network traffic, but how many clients are we talking about? If it' just 10 I wouldn't worry about it; if it's potentially 1000, then I'd worry. And maybe a check every 10 or 30 seconds would be sufficient?
What's more, server push has its own problems. You could keep a socket to the server open, but then you're using up server resources permanently although nothing much happens, and socket connection can go stale (so you'd need to send an occasional ping over them just to be sure they're still open).
The server opening a connection to the client (after the client has initially notified the server that it wishes to receive updates) is also problematic, as many desktops machines may not accept arbitrary socket connections without firewall changes.
I agree, it may not be a problem. It's also dependent on the context of the application. If it's a time critical application where data might be too stale after 30 seconds, then I'd definitely recommend the push, but for a smaller app with a single (or a few) clients, the pull system would work fine too.