Author |
Message
|
ushak |
Posted: Thu Jul 25, 2013 3:35 am Post subject: Message flow with DB operations |
|
|
Newbie
Joined: 28 Jan 2013 Posts: 8
|
Hello Everyone,
I have a message flow performing complex processing along with DB lookup and update . To improve the performance , I have
tried increasing the no of instances of the message flow but it resulted in DB locks as mutiple threads are accessing the same row of database table.
In this scenario, Is there a way to achive multi threading for message flow with database interactions? |
|
Back to top |
|
 |
marko.pitkanen |
Posted: Thu Jul 25, 2013 4:00 am Post subject: |
|
|
 Chevalier
Joined: 23 Jul 2008 Posts: 440 Location: Jamsa, Finland
|
Hi,
What is the version and OS of your broker and database ?
--
Marko |
|
Back to top |
|
 |
marko.pitkanen |
Posted: Thu Jul 25, 2013 4:10 am Post subject: |
|
|
 Chevalier
Joined: 23 Jul 2008 Posts: 440 Location: Jamsa, Finland
|
... and describe with more details you current flow: are read and update operations in the same node, what are the transaction settings, are your messages atomic (contains only one information object and its state )...
--
Marko |
|
Back to top |
|
 |
ushak |
Posted: Thu Jul 25, 2013 5:03 am Post subject: |
|
|
Newbie
Joined: 28 Jan 2013 Posts: 8
|
Broker is on Linux platform and Database is DB2.
Complete processing logic including the read/write DB operations are done in a single compute node. Flow is transactional
Each message will contain more than one information object. ie. each object can update on the same row of the table after performing select. |
|
Back to top |
|
 |
marko.pitkanen |
Posted: Thu Jul 25, 2013 5:25 am Post subject: |
|
|
 Chevalier
Joined: 23 Jul 2008 Posts: 440 Location: Jamsa, Finland
|
Ok,
My advice for you is: to study what can you do with DB2 locks & concurrency control (isolation-clause + PASSTHRU / EQSL). Consider also: can you and does it help to split logic to different nodes and flows or can you and does it help to isolate update procedure to "thread safe" atomic block inside your code.
--
Marko |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu Jul 25, 2013 5:43 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Making SELECT that are used for REFERENCE only READ ONLY makes a difference.
Sadly it is not so easy to do in DB2. In SQLserver you just use 'with (NOLOCK)' after the table name.
You can't use inline selects though so you have to use PASSTHRU. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Thu Jul 25, 2013 9:27 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
1. Put a multi-threaded WAS POJO with custom connection pool manager Web Service interface between your message flow and the database. WMB is horrible at managing database connections.
2. Put solidDb between your message flow and your database.
3. Multiply your ODBC database definitions and assign unique database definitions to each message flow instance. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu Jul 25, 2013 11:25 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
lancelotlinc wrote: |
1. Put a multi-threaded WAS POJO with custom connection pool manager Web Service interface between your message flow and the database. WMB is horrible at managing database connections.
2. Put solidDb between your message flow and your database.
3. Multiply your ODBC database definitions and assign unique database definitions to each message flow instance. |
Sigh, We know that you are a fan of SolidDB but do you really thing the OP is in a position to understand most of what you said in your post? Oh, and SolidDB costs $$$$. How many of the 'newbies' on this forum do you think are in the position to actually go to their bosses and say 'Sorry Boss we need to spend a shed load more $$$$ to make this whole rig work'. Would they actually do it even if they were in a position to do so given the reluctance of many to even question 'the requirements' they are given to work on?
Remember,
- not every DB problem needs SolidDB
- not every newbie needs to go on a training course before they are qualified to ask questions. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Thu Jul 25, 2013 11:30 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
smdavies99 wrote: |
lancelotlinc wrote: |
1. Put a multi-threaded WAS POJO with custom connection pool manager Web Service interface between your message flow and the database. WMB is horrible at managing database connections.
2. Put solidDb between your message flow and your database.
3. Multiply your ODBC database definitions and assign unique database definitions to each message flow instance. |
Sigh, We know that you are a fan of SolidDB but do you really thing the OP is in a position to understand most of what you said in your post? Oh, and SolidDB costs $$$$. How many of the 'newbies' on this forum do you think are in the position to actually go to their bosses and say 'Sorry Boss we need to spend a shed load more $$$$ to make this whole rig work'. Would they actually do it even if they were in a position to do so given the reluctance of many to even question 'the requirements' they are given to work on?
Remember,
- not every DB problem needs SolidDB
- not every newbie needs to go on a training course before they are qualified to ask questions. |
I was suggesting three options, only one of which was solidDb. The other two options do not require license purchases. I would be re-miss if I did not state the obvious turn-key solution of solidDb. Some applications require that type of through-put. Would you agree ? _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
|