This is regarding the side-effects of using basic adapter notification . I have decided to use basic notification since i need 100% processing of transactions without a miss. But as per my knowledge the trigger continuously polls the target DB and creates a buffer table. Thats perfectly logical. But is there any effect on the performance of the other processes(Non wM) accessing the same DB?(Due to locking for read etc). Since its a financial transaction DB, first priority is transaction from core banking software and then middleware comes into picture.
I do see with SQL Server some issues like dead lock victim etc… (especially when dealing with transactional connection type) and it can degrade the performance when heavy volumes (back and forth) of course it totally depends on the DB env how it was setup and configured parameters handling etc…Even when set to selectMethod= direct but still we see dead lock errors intermittently.
So even though you have basic notifications and regular db services it should’nt degrade IS performance assuming the IS are in cluster and vigorously Integration tested all the various scenarios and bottle necks.
Thanks for the reply. Yes, its Oracle 9i or 10g(Need to check).Our Initial design was to use scheduler extracting the data in regular intervals. But scheduler doesnt have option for intervals < 1 min. cx wanted it to be in seconds(15 to 30 Secs).
Any other suggestion for efficient approach are welcome.
Ok. Ya anyways simple repeat is in seconds, can manage. But which approach is efficient for high volume transactions? Scheduled approach or Adapter Notification?.
Just to let you all know, I have done it using scheduler approach and its perfectly fine for load requirements.
Its taking around 5 s for 250 transactions and it suffice my client requirement. Reason I went for it is, i didnt want to put more load on broker.
Scheduler is also a good approach but make sure your system has enough thread resources available time to time… We have some high volume interfaces which uses scheduler based too…
But Broker is always meant to deal high volume pub/sub model and I don’t see any bottle necks using the notification based as long as you have done proper load/volume testing and cross the hurdles.
Can you advise the hurdles experienced when usng basic notification in high volume scenario. We have been using the standard polling notification, but irrespective of the settings we tweak, cannot get it to process more than 2 records a second (as per my other open thread).
When you say, “Scheduler” based, what are you actually referring to?
. I have decided to use basic notification since i need 100% processing of transactions without a miss. But as per my knowledge the trigger continuously polls the target DB and creates a buffer table. Thats perfectly logical. But is there any effect on the performance of the other processes(Non wM) accessing the same DB?(Due to locking for read etc). Since its a financial transaction DB, first priority is transaction from core banking software and then middleware comes into picture.