World Persistence, flat files v/s DB v/s ??

[s001gmu at nova.wright.edu]

On Sun, 22 Mar 1998, Matt Chatterley wrote:

> On Sun, 22 Mar 1998, Chris Gray wrote:
> > [Ben Greear:]
> 
> [Snip]
> 
> > :Also, as a java server, I don't think I can do a select on incomming
> > :data.	I think a thread for every player is a bit much...any suggestions
> > :here?
> > 
> > I have just started into the socket programming stuff of the current Java
> > book I'm reading, but I just went and did some scanning. The technique
> > he suggests for a server is to create some fixed number of threads, and
> > re-use those threads throughout the lifetime of the server. He says that
> > some Java implementations do not garbage collect threads at all, so having
> > one per connection can result in an eventual crash due to lack of memory.
> > Ick. Given the lack of a 'select' or 'poll' method in Java, the choices
> > are quite limited. Double ick.

[...]
 
> Reusing threads is probably desirable, by the way, especially if less work
> will be done to re-use an existant thread than to create a new one, and
> not hard to do.

As I understand it, it is usualy a LOT less work to reuse a thread that to
destroy/create a new one.
 
> Consider a model where you have a resizeable array (see the Vector class)
> of Threads. You also maintain a list of available threads so you do not
> have to recalulate it, and follow a procedure akin to:
> 
> New connection is made to the server:
> 	Check list of available threads.
> 		If null: extend the Vector and add a new thread to handle the
> 			connection.
> 		If not null: take the 'top' thread and re-assign it.
> 
> A connection closes:
> 	Add that thread to the list of available threads.
> 	Suspend and 'reset' the thread.
> 
> Seems interesting anyway. :)

This is very similar to a discussion we had about multi-threading event
drivers.  You might also consider, to reduce the number of creates and/or
unused threads at the end of your array, a pool approach, with a min/max
available setting.  Something like so:

You create the pool (array, call it what you will), with min/max avail set
to 2/5.  It starts with 5 avail (all unused).  One person connects.  no
problem.  Then 3 more connect.  Now we have 4 in use, 1 avail, so the pool
adds a new thread, taking the total count up to 6, 4 in use, 2 avail.
lets say everyone then logs out.  The pool has 6 avail, so it deletes
one, to maintain the max avail at 5. This scheme works well, as long as
you don't change the number of threads in use too radically.  Constant,
radical changes in number will prolly just add overhead to a simpler
scheme, but as long as it fluctuates within the range you specify, it
shan't create or destroy any threads.

I liked the model, but haven't adopted it for my event driver.  I want to
run some tests with a static pool first, and see if I really do need a
dynamic pool.

-Greg