Timesten Error 8521

Question

Hi,
When application tries to connect to database I see the following error from timesten, the scenario is initially when first time the application which is connecting to timesten makes the connection without any problem, when connection is still open and tried to restart the timesten (ttDaemonAdmin -stop/start) and when application retries to connect the following error is seen, if again the application is restarted it will connect fine, i have also collected the ipcs -m command o/p,
Before timesten restart,
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x5d0082d2 14516231 timesten 660 1048576 1
0x0c00800d 14549000 timesten 660 1159224112 2
0x0d00800d 14581769 timesten 660 33554432 2
After Timesten restart,
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x5d0082d2 14614535 timesten 660 1048576 1
0x00000000 14549000 timesten 660 1159224112 1 dest
0x00000000 14581769 timesten 660 33554432 1 dest
Caused by: java.sql.SQLException: JDBCUpdateRule.checkDBConnection: could not connect to the database: java.sql.SQLException: JDBCUpdateRule.connectToDatabase() : java.sql.SQLException: [TimesTen][TimesTen 11.2.1.6.1 ODBC Driver][TimesTen]TT8521: Cannot attach PL/SQL shared memory; virtual memory at PLSQL_MEMORY_ADDRESS already in use by TimesTen -- file "db.c", lineno 9830, procedure "sbDbConnect"
Caused by: java.sql.SQLException: JDBCUpdateRule.connectToDatabase() : java.sql.SQLException: [TimesTen][TimesTen 11.2.1.6.1 ODBC Driver][TimesTen]TT8521: Cannot attach PL/SQL shared memory; virtual memory at PLSQL_MEMORY_ADDRESS already in use by TimesTen -- file "db.c", lineno 9830, procedure "sbDbConnect"
Caused by: java.sql.SQLException: [TimesTen][TimesTen 11.2.1.6.1 ODBC Driver][TimesTen]TT8521: Cannot attach PL/SQL shared memory; virtual memory at PLSQL_MEMORY_ADDRESS already in use by TimesTen -- file "db.c", lineno 9830, procedure "sbDbConnect"
what is the possible cause for this situation?
Edited by: user1074825 on Apr 17, 2011 6:26 AM

Answer 1

In direct mode, a 'connection' to TimesTen is really a shared memory attach/mapping. As such it behaves quite differentyl to a normal TCP/IP type connection and applications must be sure to behave 'properly'. If a datastroe fails (we use the term 'invalidation') while an application has a direct mode connection then the next time the application tries to perform any database operation it will get an error/exception with a TimesTen native error code of 994 or 846. When it receives one of these errors the application must, for each connection that it has, do the following:
1. Execute a rollback. This rollback may itself return an error / throw an exception but this can be ignored.
2. Disconnect the connection.
Unless the application does this, the 'defunct' shared memory segment(s) (datastore and maybe Pl/SQL segment) will (a) remain allocated (and visible via ipcs) and (b) remain attached ot the process, possibly preventing the process opening any new connections.
This is what you are seeing in your 'experiment'. Stopping the TimesTen daemon (why are you douing this by the way? Stopping the daemon should usually be a system startup/shutdown type of thing; it is unusual to stop the daemon at other times) will invalidate (i.e. crash) all datastores beign managed by the daemon. TimesTen cannot clean up the defunct shared memory segments as the application still has them attached. The daemon comes back up and new applications can connect fine but the existing application still has the old shared segments attached and so cannot 'reconnect'.
Regards,
Chris