Table pools in Turbine?

[Lester Ward <lw...@tagaudit.com>]

Long explanation, followed by a question:

My Turbine application manages state information on its own (not relying on
the session from the application server). The way I do this it to generate a
random number on login, create a record in the database with that number as
the key (with data about the user, last access time, etc.) and then return a
cookie with the session id to the user. On the next access, we get the
session id, do a database lookup to determine who it is and continue. (The
main advantage of this is that when the user moves to the next page, they
can be directed to an entirely different server and still have state.) There
are other ways to do this, but this is a typical strategy.

One drawback is that under heavy load, the logon process that inserts
session records can develop table locks, because every logon is trying to
alter the same table.

I've had some success dealing with this problem by creating a "pool" of
session tables. They are given the name SESSON_*, where * is a number. In a
config file, you set what * is, and you make sure that you create that many
tables in the database. So, for example, set you set the number of tables to
3. You'd have to create tables SESSION_0, SESSION_1 and SESSION_2.

When access the table, you use the session key to determine which table to
use. Basically, you just mod the key with the number of tables:

    static protected final String kTable_StateTableRoot= "SESSION_";
    protected String getStateTableNameByKey( long key )
    {
        int totalTables = getStateTableTotal();
        int tableInt = key % totalTables;
        String tableSuffix = String.valueOf( tableInt );
        return kTable_StateTableRoot + tableSuffix;
    }

How well would turbine support something like this in terms of its object
model? I'd like to be able to have just a single session object class, and
have the peer classes figure out what table to use at runtime. Does this
sound possible? How would I go about it?

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>