[MUD-Dev] World Persistence, flat files v/s DB v/s ??

[Vadim Tkachenko]

s001gmu at nova.wright.edu wrote:
> 
> 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.

Once again, for those interested there is the implementation of two
pairs:

Packet/PacketSwitcher
Channel/ChannelSwitcher.

Implement the minSpare/maxSpare concept, with the addition: maxRunning -
I run into it when I needed to support the evaluation copy with a limit
of 2 concurrent connections :-))

Packet and Channel are the resources to share, just as an example -
database connection with autocommit is a Packet, database connection
which you need to commit/rollback manually is a Channel.

Switcher, respectively, is an object which maintains the proper number
of available resources in according to guidelines.

> -Greg

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are