Further Data on [ERRSTR = org.hibernate.exception.JDBCConnectionException: could not load an entity: [com.tibco.tibems.tibemsd.internal.db.HBLock#1] ]

Further Data on [ERRSTR = org.hibernate.exception.JDBCConnectionException: could not load an entity: [com.tibco.tibems.tibemsd.internal.db.HBLock#1] ]

book

Article ID: KB0081087

calendar_today

Updated On:

Products Versions
TIBCO Enterprise Message Service 8.1.0

Description

This exception can be caused by EMS losing a connection to the database; either the database is not running or there was some intermittent network problem between the machine running the database server and the machine running the EMS server. Clients have also reported seeing this when database was available. 

 

Issue/Introduction

Clients running EMS in FT setup have reported seeing this error output in the EMS logfile. As per KB article 33920, this can be caused by EMS losing the connection to the database; either the database is not running or there was some intermittent network problem between the machine running the database server and the machine running the EMS server. Clients have also reported seeing this when the database was available.

Environment

Windows Server 2008 R2

Resolution

Some clients have also reported seeing these errors reported for brief periods even when the database is available for use. Seeing these advisories for short periods can be explained due to the EMS server's internal handling of running in FT mode. Essentially, when the first FT server starts, a shared lock is placed on internal DB table which helps stop the secondary server locking this.

If the first server is ungracefully shut down, the entry remains in the table  meaning the secondary server can't update the lock (resulting in the error you see) for a period of 10 seconds after which it seems the secondary server can update the lock. If the first server is gracefully shutdown  the entry in the database table is immediately cleared meaning the secondary server can place a lock on the database straight away.

It appears that this is default behavior for EMS FT servers running against a database. If a client is only seeing these errors reported for a short period (10 seconds ) this is likely to be the reason.