| Author |
Message
|
| opmind |
 Posted: Wed Jun 01, 2005 9:01 am Post subject: How to configure session time from DataFlowEngine to db2? |
 |
|
Acolyte
Joined: 04 Dec 2001
Posts: 68
|
Hello there,
We have a production database A, a lot of our flows access to this database ( catalog remote ) to select and update. Everything runs well...
Every night, our database is stopped to be backed up. But our Message Broker is not.
On the morning, the first flow failed !!! And the second one is ok.
It seem's that WBI catch a session and when it tries to access ( after the stop start of db2 database ) it tries to access to this session... and of course, fail.
My question is : is it possible to configure a timeless session ? I mean is WBI is able to disconnect himself to the database just after some minutes ?
Thx,
Cyril |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jun 01, 2005 9:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Just stop the broker while the database is stopped.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| opmind |
| Posted: Wed Jun 01, 2005 10:04 am Post subject: |
|
|
Acolyte
Joined: 04 Dec 2001
Posts: 68
|
| Lol... The problem is that WBI is on an HACMP cluster for a 24/7'a day !!! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 01, 2005 10:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
But if the broker database is down, you're not going to get broker processing!
So you either need to ensure your database is 24/7 or stop the broker temporarily.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| opmind |
| Posted: Wed Jun 01, 2005 10:22 am Post subject: |
|
|
Acolyte
Joined: 04 Dec 2001
Posts: 68
|
| In fact the database which is stopped is an application's database not broker, even not configmgr... BKDB and CMDB are online 24/7 . Everything runs well on that part... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 01, 2005 10:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Ah.
Then just increase the backout threshold on your input queues - the first try will fail, the message will get rolled back, the second try will succeed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fschofer |
| Posted: Thu Jun 02, 2005 2:04 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
You may have to modify the error handling in your flows to get this working.
| Quote: |
| Then just increase the backout threshold on your input queues - the first try will fail, the message will get rolled back, the second try will succeed. |
Greetings
Frank |
|
| Back to top |
|
|
| Ian |
| Posted: Thu Jun 02, 2005 3:34 am Post subject: |
|
|
Disciple
Joined: 22 Nov 2002
Posts: 152
Location: London, UK
|
You have 2 options, (1) either go with Jeff's suggestion and recycle the broker at the same time as the database or (2) write an WBIMB flow error routine
Refer to WBIMB v5.0 documentation under topic "ac00406_" which covers "User database connections" :
| Quote: |
User database connections
Determine the number of database connections required by a broker for capacity and resource planning. A database connection is made by the broker to the ODBC data source name (DSN); a connection is made for each DSN even if different DSNs resolve to the same physical database.
The number of connections required by the broker to a user database depend on the actions of the message flows that access the database. For each broker that accesses a database, one connection is required for every ODBC data source name (DSN) for each message flow thread. If the same DSN is used by a different node on the same thread, the same connection is used unless a different transaction mode is used, in which case another connection is required. This is explained further in Database connections for coordinated message flows.
When you start a broker, it opens all the connections that it requires. The broker caches these database connection handles for performance reasons. For example, when a message flow node initiates access to a user database, it opens a connection for the data source. This is done the first time that a message is processed by that message flow node. This connection remains open until the execution group or broker is shut down.
If you are using the same database for user application data and for broker internal data, add the two connection requirements together when you calculate how many connections are required. For details of broker database connection requirements, see Connecting to the databases.
If you stop the broker, it releases all current database connection handles.
If you are using DB2 for your database, the default action taken by DB2 is to limit the number of concurrent connections to a database to the value of the maxappls configuration parameter. The default for maxappls is 40. If you believe that the connections that the broker might require exceed the value for maxappls, increase this and the associated parameter maxagents to new values based on your calculations.
If you are using another database, check the appropriate product documentation for information about connections and limits or restrictions.
|
To further explain ... if the Broker is not brought down when the database is stopped, then the cached database connections that the Broker has are no longer valid. The default behaviour is that we will throw an exception, and release (delete) the invalid connection handle. Depending on how the message flow is wired, the in-flight message will either be routed down a failure path or rolled back to the input node (and then down the catch or failure path if wired). The next message that gets processed will ask for a database connection for the current thread, determine that there isn't one cached, and so create a new connection.
What this means is that the first message processed after the database has been recycled will receive a database connection exception. Subsequent messages will be processed successfully. If you choose not to recycle the Broker at the same time as the database then you should code an error routine which will check for the database specific exception and reprocess that first message.
_________________
Regards, Ian |
|
| Back to top |
|
|
|
|
