ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Message flow with DB operations

Post new topic  Reply to topic
 Message flow with DB operations « View previous topic :: View next topic » 
Author Message
ushak
PostPosted: Thu Jul 25, 2013 3:35 am    Post subject: Message flow with DB operations Reply with quote

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
View user's profile Send private message
marko.pitkanen
PostPosted: Thu Jul 25, 2013 4:00 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
marko.pitkanen
PostPosted: Thu Jul 25, 2013 4:10 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
ushak
PostPosted: Thu Jul 25, 2013 5:03 am    Post subject: Reply with quote

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
View user's profile Send private message
marko.pitkanen
PostPosted: Thu Jul 25, 2013 5:25 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
smdavies99
PostPosted: Thu Jul 25, 2013 5:43 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Thu Jul 25, 2013 9:27 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
smdavies99
PostPosted: Thu Jul 25, 2013 11:25 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Thu Jul 25, 2013 11:30 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Message flow with DB operations
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.