I'm creating a text-based game, Dirt. I've the bottom functions from the program ready, and today I must let it connect several client at any given time. I intend to use threads to complete that.

During my game I have to store information for example present position or health points for every player. I possibly could hold it within the database, but because it can change extremely swift, sometimes every second, using database could be inefficient (shall we be held right?).

My real question is: can threads work as "periods", ie hold some data unique to every user?

If so, would you direct me with a assets which i can use that helped me to experience how it works?

If no, exactly what do you suggest? Is database a great choice or can you recommend another thing?

Cheers, Eleeist

Yes, they are able to, but this can be a mind-bogglingly stupid method of doing things. To begin with, it permanently locks you right into a "one thread per client" model. For an additional factor, it causes it to be difficult (possibly even impossible) to implement interactions between customers, which I am sure your Dirt has.

Rather, have an accumulation of some type that stores your customers, with data on each user. Save persistent data towards the database, but you don't have to update ephemeral data on every change.

One method to handle this really is to possess a "transformed" boolean in every user. Whenever you create a critical switch to a person, write these to the database immediately. But when it is a routine, non-critical change, just set the "transformed" flag. Then possess a thread arrive every every now and then and create transformed customers towards the database (and obvious the "transformed" flag).

Use appropriate synchronization, obviously!

A Thread per connection / user session will not scale. You are able to have only N quantity of threads active where N is equivalent to the amount of physical cores / processors your machine has. You're also restricted to the quantity of memory inside your machine for the number of threads you may create a period, some operating systems just put arbitrary limits as well.

There's nothing magical about Threads in handling multiple clients. They'll simply make your code more difficult and fewer deterministic and therefore harder to reason by what is really happening when you begin hunting logic errors.

A Thread per connection / user session could be an anti-pattern!

Threads ought to be stateless employees that pull things off concurrent queues and process the information.

Take a look at concurrent maps for caching ( or apply certain appropriate caching solution ) and process them after which make a move else. See java.util.concurrent for the primitive classes you have to implement something properly.

Rather than worrying about threads and thread-safety, I'd make use of an in-memory SQL database like HSQLDB to keep session information. Among other benefits, in case your Dirt works out to become the following Angry Wild birds, you can easier scale the one thing up.

ThreadLocal is the friend! :)

http://docs.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html

ThreadLocal provides storage around the Thread itself. Therefore the identical call from 2 different threads will return/store different data.

The greatest danger is getting a leak between Threads. You would need to be certain when another user used a Thread that another person used, you'd totally reset/obvious the information.

Certainly you should use threads as periods. But it is a little from the mark.

The primary reason for threads is ale concurrent, asynchronous execution. Most most likely, you don't want occasions received out of your Dirt clients to occur within an parallel, out of control order.

To make sure consistency around the globe I'd make use of an in-memory database to keep the overall game world. I'd serialize updates into it, or at best some updates into it. Imagine two gamers in parallel striking a monster with Hewlett packard 100. Each deals 100 damage. If you do not serialize the updates, you can finish up giving credit for 100 harm to both gamers. Imagine two gamers concurrently taking loot in the monster. Without correct serialization they might finish up each using their own copy from the loot.

Threads, however, are great for asynchronous communication with clients. Use threads for your, unless of course another thing (just like a web server) does that for you personally already.