| Martin Phillips 2006-12-08, 7:40 am |
| Can you tell us what version of WAS you are using, and what database you are
using please, also when you are getting problems with this?
The WebSphere Application Server V6 System Management and Configuration
Handbook does not include information on enhancements that were made to some
Messageing Engine behavior related to databases that came along in WAS 6.1
(as the Redbook was produced based on was 6.0).
The statement in the Redbook about deleting tables from Cloudscape is very
specifically ONLY for Cloudscape, and ONLY to be done when you have deleted
and recreated a Bus/Messaging Engine with the same name as the old one on
WAS 6.0. This behavior was updated in 6.1.
--
Martin Phillips
mphillip@uk.ibm.com
<rodrigo.felicio@gmail.com> wrote in message
news:329840139.1165501838211.JavaMail.wassrvr@ltsgwas010.sby.ibm.com...
>
> 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 establish 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
> situation, 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.
|