I am working at client site, where they have 3 - 4 components working on a single Oracle database. They have configured separate adapter instances for each of these components. The reason is pending documents of one component should not block other components.
I wish to know if this is good strategy?
Does it really affect the performance?
How does it affect to the database in terms of connections made or resource used?
Oracle Intelligent adapter doesn’t provide multi-threading capabilities. Then how to tune the adapter for performance?
Regards,
Vandana.
Hi Vandana,
Is there a specific reason why you are working with the Oracle adapter instead of the JDBC adapter? We at one time considered the use of the Oracle adapter but we decided to use the JDBC adapter.
Indeed, it seems overkill to me to use an adapter for each component. What are your limitations? What do you mean with the fact that the integrations shouldn’t block eachother? If you are worried about problems at one DB impacting your other integrations, this is clearly not an issue since you are working on the same DB.
What is the load? Are you having constraints there?
Take into consideration that in most cases it is not a good practice (design, performance, maintainability) to have adapters for each integration component.
Rgrds,
cdrc
Hi Cedric,
The Oracle Adapter is used because the client started work before JDBC adapter was released. What are the benefits of using JDBC adapter? If there is any considerable gain then I can discuss it with the client.
By blocking each other I mean, documents from various sources are accumulated in the adapter client queue. Each integration component is triggered by different document types. If there are multiple components and if some component takes more time for processing, then the other components are held till the component process is complete. The load is around 4K activations for one component and around 6K activations on all other components together in a day.
These are developed as per client’s architecture. I need to collect information, so that I can discuss these with client.
Regards,
-Vandana.
Hi Vandana,
Let’s give your client a compelling argument: As far as I know the Oracle adapter is not supported anymore by webMethods or will not be supported in the future (cfr. the adapter which is provided on the platform 6 is a JDBC adapter). On top of that, a JDBC adapter is not limited to Oracle databases and as you said before, the JDBC adapter can run in seperate threads.
I took a look at the loads you provided. They don’t seem that heavy to me (an average of 0,3 per second) which is perfectly manageable with only one adapter. On average the max load is about 4-5 events per second (according to the Enterprise 4.0 Benchmark - There are probably newer benchmarks since then). However, the benchmarks only describe an insert on the target database, maybe your integrations are a lot more complex… But anyway, I don’t think your client should be concerned with blocking events (under the condition that the load will not be increased significantly in the future).
Hope this helps.
Kind regards,
Cedric
Hi Vandana,
I too face similar kind of problem.
As the number of documents in the queue gets accumulated,the processing times gets slowed down.
Can you please share with me on how did you go for improving the performance of the oracle adapter?
Hi, Bneelima:
If there are not any “outbundle” calls (PublishandWaitforReply) within the integration components on the Intelligent Oracle adapter, you can increase the number of adapter sessions at “# of adapter processes” to improve the adapter performance.
Hope this will work for your case.
Hi zhi-gang_wei,
We prefer sequential processing rather than parallel processing,that is,document 1 should get processed earlier to document 2.
In such cases,is it recommended to increase the adapter processes?
If not,what would be the other option?
Regards,
Neelima
If order of processing is important, then you can’t increase the number of adapter processes or you risk running into a race condition whereby you can’t guarantee processing order.
wrt Cedric’s comment: “…that in most cases it is not a good practice (design, performance, maintainability) to have adapters for each integration component.”
There are advantages to doing exactly this. Having an adapter for each component:
- Allows restarts/updates of a components without disturbing other processes.
- Failures in one component do not disturb other components.
- Distributes the workload among adapters, which can be distributed on multiple machines.
Logical design-wise, there is no real difference between one adapter for all components vs. one adapter for each component from the component standpoint. The component doesn’t care what adapter it is running on.
An adapter for each component could actually improve overall throughput.
The downside of course is the increased number of adapters that must be administered. As with most design decisions, it’s a trade-off to determine which set of pains you want to live with.
Hi Neelima,
I am curious about how you realized sequential processing.
Lets assume, that you have one subscriber for a document type. To get this subscriber excuted sequentially - what do you do ?
Restrict the capacity of the trigger to one and set the umber of concurrent threads to one ?
And what do you do when the service specified for the triggered document fails ? The documents gets lost … Do you have any strategy to prevent from this ?
Cheers,
Andreas