Cannot reconnect to Timesten Data Store

Question

Hi,
I'm using TimesTen 6.0.1 on Linux Red Hat AS 4.
My application connects well to the data store.
Then when I do:
/sbin/service tt_tt60 restart
My application is disconnected from the DS (normal), but after the data store is back, my application tries to connect again, and it does not work. I see this error log:
Sep 21 17:05:26 intel1 TimesTen Data Manager 6.0.1.tt60[11638]: ODBC_ERROR: sqldbthread 0: 3- ERROR -1 in sqlDBv2/sqldb_api.c, line 154: Error in connecting to the driver
Sep 21 17:05:26 intel1 TimesTen Data Manager 6.0.1.tt60[11638]: ODBC_ERROR: sqldbthread 0: 4- [TimesTen][TimesTen 6.0.1 ODBC Driver][TimesTen]TT0837: Cannot attach data store shared-memory segment, error 12 -- file "db.c", lineno 8623, procedure "sbDbConnect()" *** ODBC Error/Warning= 08001, Additional Error/Warning= 837
errno 12 is pointing to not enough memory
PermSize in sys.odbc.ini is 1800
If I change PermSize to 1000, it works well, the application reconnects well to the data store. But reducing PermSize would severely affect the max number of entries we can put in the database.
So, is there a way to recover from such a case without changing PermSize?
Christophe

Answer 1

I think we need more information to understand exactly what is happening here. Here are a few observations and suggestions:
1. When the datastore gets 'invalidated' due to the main daemon being stopped (restarted), and your application gets the error (846 or 994), what does it do? It must (a) issue a rollback on all its connections ot the DS and (b) issue a disconnect on all its connections to the DS> Until this is done, the shared memory segment for the DS will remain in existence and 'attached' to the application process. Only when the above has been done will the DS segment be released. You could use the O/S ipcs command before and after the daemon restart to see if the DS segment remains or not.
2. The O/S is denying the request to attach a new segment to the application process. The error is ENOMEM which does not necessarily mean not enough actual memory. Most likely some kernel parameter or process limit parameter is set too low such that when you trya and attach the second segment (since I suspect, as described above, that the first segment is still attached to the application) it fails. Or it may truly be that you do not have enough address space left (is this 32-bit or 64-bit) to attach the new segment.
I would recommend investigating the issues I describe in (1) above as a first step.
Chris