This may be it; right from Metalink:
Cause:
This is an issue with loading the sessions.xml file, once when the application was first deployed using that application's classloader and then not reloading the session when the application was redeployed and a new XMLContext was created. The caused us to attempt to use a session that had been loaded with a different classloader than the current application.
Possible solution:
The issue occurs when TopLink is part of the main classpath (Eg: Applib directory rather than stored in the ear file). When this happens, the static SessionManager has trouble finding descriptors the second and subsequent times an application is deployed. Basically the descriptors are indexed by class. When the application is redeployed, the classes used for the indexing are unloaded and new versions of those classes appear. This causes "Descriptor not found" exceptions.
Potential Workarounds
Put the toplink.jar file in the ear.
Write some code to manually clean up when the toplink application is torn down.
For certain architectures they may be able to use the version sessionManager.getSession() that allows the session to be refreshed.
Workaround 3 is best and very feasible. The session has to be lazily obtained from the SessionManager and held in an application code variable. When the application is restarted its handle on the TopLink session will be null. The session can then be obtained from the SesssionManager using the getSession(XMLLoader xmlLoader, String sessionName, ClassLoader objectClassLoader, boolean shouldLoginSession, boolean shouldRefreshSession) API with shouldRefreshSession set to true. This will ensure that the old session (if any) is logged out and removed from the SessionManager before a new one is created.
Did any of the workarounds help?