|
Home > Archive > WebSphere Application Server > December 2006 > [WAS-V6.1]: Question regarding data store tables handling (why
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[WAS-V6.1]: Question regarding data store tables handling (why
|
|
|
|
Hi everyone.
Does anyone could explain how the access to data store tables by messaging engine works? I ask it because sometimes the WAS machine gets restarted (somebody just stumble at the taking, for instance) and WAS loses the DB connection. When it tries to establ
ish the DB connection again (after restarting) the messaging engine (there's only one configured) isn't able to get access to the SIBOWNER due to a lock occurred by the instance which was interrupted by the restart of the machine. After describing the sit
uation, here are my questions:
1. Why does WAS need to lock the SIBOWNER table?
2. Isn't WAS able to handle this kind of situation by itself? Why do I need to remove MANUALLY the data store tables? Is there anyone working to improve it? Isn't there any better way to do it?
(The remove manually approach is described in the page 625 of the WebSphere Application Server V6 System Management and Configuration Handbook)
3. Is it possible to change this behavior? How? Could anyone, please, send a step-by-step tutorial or where to find it out? And if it isn't possible, why then?
(I ask it because for instance, if this happens in a production environment, I guess it could be necessary the intervention of a DBA in order to unlock the table and so WAS be able to use the data store again.)
Tks in advance,
Rodrigo.
| |
| David Currie 2006-12-08, 7:40 am |
| Hi again,
The database locks are used in the case where you have a clustered
messaging engine to ensure that if the HA manager attempts to start the
same messaging engine on multiple servers (for example, because the
network between them has become partitioned) one of them will fail. If
the lock isn't being released when the database connection is dropped by
WAS being restarted then that's an issue you need to address on the
database side.
Regards,
David
|
|
|
|
|