| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| A single DSN versus multiple DSN's for a single SOR |
« View previous topic :: View next topic » |
| Author |
Message
|
| aspre1b |
 Posted: Wed Jan 31, 2018 1:28 am Post subject: A single DSN versus multiple DSN's for a single SOR |
 |
|
Voyager
Joined: 05 Jul 2007
Posts: 78
Location: Coventry, UK
|
I'm just looking to get people's view on the use of DSN's for accessing system of records.
Would anyone advocate having different DSN's for a single database schema that is accessed through multiple execution groups. For example each DSN would utilise a separate DB user. The benefit I see is that from a database point of view, there is an audit of which users are accessing the tables, and thus can be traced back to an execution group (and thus a project/channel/application).
It's not a perfect solution, as a DSN set up on a broker instance, is accessible to all execution groups. This would mean it would be down to peer review to make sure the correct DSN is used.
The datasource in question, is the primary system of record, and not a local broker database.
Going a step further, any views on having a different DSN for Create/Update operations, versus Read operations. This has been mooted for message flows that perform payment transactions.
I'd be interested to learn how DSN's have been set up at other companies?
If the datasource in question was owned by the broker (e.g. exception table), then I would expect a single DSN, as it is typically accessed via standard exception handling flow. |
|
| Back to top |
|
 |
| abhi_thri |
| Posted: Fri Feb 02, 2018 6:45 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
I don't think it is good idea to have multiple DSNs just for the sake of it, as you mentioned it would be hard to police as flows across the estate (within the same or diff EGs) will have access to it. Also you need to be wary about the maintenance overhead when no. of EGs increases in future.
Having that said I've seen cases whether a separate DSN was used (a DB polling flow had to meet some specific throughput criteria and the DB admin preferred a new user id to keep track of things).
Also have seen the case of a read only DB user id used to access a reference database owned by a separate app.
So a separate DSN may prove useful in certain scenarios but using a blanket rule of DSN per EG may prove troublesome in the longer run.
PS: If the no. of active DB threads is a concern you should be looking at caching DB entries where possible (eg:- most of the read scenarios involving static data could be cached) |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
