Your requirements are going to be hugely different if the game you're writing is a twitch game (fps, flight sim, etc) that requires updated world data 60 or more times a second vs an RTS that can manage a handful of times per second vs a true strategy game that only needs updates as other players make decisions.
A SQL database is both too slow and overkill for twitch games; for a sprawling strategy game it might be a reasonable choice. In a slow strategy game you can coordinate everything via updates to the db by the clients: reality lives in the database, and everyone has a consistent view of the world (though the client may hide some of this from the human player) via views of the db. The networking details are all hidden from you as a programmer, since this is really just a (well-defined) matter of connecting to a remote db. This is elegant, easy, and slow.
That's not going to work for a fast game, however. Twitch games are typically sending and receiving TCP or UDP packets to the server (in server-based games) or each other (in p2p games). I think there are some games using binary http as well, to avoid issues with firewalls and ports.
The game is going to be a 3 player chess game. The program in Java will be installed on each machine. When the user of whatever machines makes a move I was going to have it send to the database then that move would be sent to the other users.
After that the Java program on the user’s computer would do the animation of the move and whatnot.