[ts-gen] Sequential database record indices

Bill Pippin pippin at owlriver.net
Wed Jul 21 10:41:29 EDT 2010


Vince,

With respect to previous posts:

> ... Bill and Jordi ... Thanks again for the timely responses to
> both questions. ...

You're welcome.  It's good to know when or if reported problems
have been solved.

> ... tried the innodb lock with both the "0" and "2" settings
> (and a restart naturally) w/o success.  ...

I understand that you restarted the mysql db server process
each time.  Did you, however, recreate (setup.sql, for both)
or at least repopulate (create.sql, for either trading or
testing) the databases?

When you see problems due to holes in the index sequence for
a table's record indices, those records need to be replaced.

Note that you are fixing mysql, not the shim, and for sql
insert at setup, not sql read access at shim start.  The shim
works just fine, the problem is that recent versions of mysql
no longer necessarily deliver on the promise originally made
for the auto_increment attribute declaration, that unique
ids be incremented, as opposed to the next value chosen by
the server jumping ahead erratically.

I realize that you may have meant "recreate" or "repopulate" in
place of "restart" above; I mention this point in the hopes your
meaning was exact, since recreation is an easy fix.  I also
realize that you have been reviewing the archives on this issue,
and may have already read the following:

http://www.trading-shim.org/pipermail/ts-general/2009-May/000415.html
http://www.trading-shim.org/pipermail/ts-general/2010-April/000724.html

I mention them here in case you missed them --- there are many posts
on this issue, spread over more than a year --- and for the benefit
of other readers who may not have seen them yet.  Good luck with
getting the shim to startup successfully, and please keep us posted.

Once you get the shim to start up successfully the first time,
operation thereafter is much easier.  The shim is meticulous about
checking inputs at startup, which is one reason it is so robust
once initialization is complete.  It's been designed and implemented
according to the optimization principal of "fail early", which calls
for avoiding time consuming exploration of a large search space when
available, up-front constraints show the search would fail.

Thanks,

Bill


More information about the ts-general mailing list