Hi,
Database adapter is used to poll/retrieve diferent kind of records from datatbase.
Consider a case:
We are polling a table, which is rapidly updated by another process.
So now every polling cycle , the eligible records for the DB poller , will be huge in number.
And in cases where the data retrieved is metadeta related to some other information like Batch id or OrderId , which are used to retrieve more information , then the server will not be able to handle such amount of data, even in case it handles there will be a huge performance impact.
How to restrict this kind of behaviour ?
During configuring our DB poller, we have few performance parameteres:
then the next 20 records will be retrieved and creates 2 instances with 10 records each....
and this process continues until all records are processed with the appropriate read value.
Database adapter is used to poll/retrieve diferent kind of records from datatbase.
Consider a case:
We are polling a table, which is rapidly updated by another process.
So now every polling cycle , the eligible records for the DB poller , will be huge in number.
And in cases where the data retrieved is metadeta related to some other information like Batch id or OrderId , which are used to retrieve more information , then the server will not be able to handle such amount of data, even in case it handles there will be a huge performance impact.
How to restrict this kind of behaviour ?
During configuring our DB poller, we have few performance parameteres:
- Database rows per XML document
- Database rows per Transaction
If we want to pick only 10 rows at a time i.e., only 10 rows per one instance , then we need to give the value 10 for the property called "database rows per XML document"
This creates an xml with 10 elements and is passed through a single Oracle BPEL Process Manager instance.
Assume that there are 100 rows at the start of a polling interval and that "Database rows per Transaction" is 10.
In standalone mode, a cursor is used to iteratively read and process 10 rows at a time until all 100 have been processed, dividing the work into 100 / 10 = 10 sequential transactional units.
Note: "Database rows per Transaction" value must be equal or greater than "database rows per XML document"
Example:
lets say 100 records to process in DB.
"database rows per XML document" as 10
"database rows per transaction" as 20
This is how it behaves at runtime:
First the database adapter gets 20 rows from database and now 2 instances will be created with 10 records in each.
then the next 20 records will be retrieved and creates 2 instances with 10 records each....
and this process continues until all records are processed with the appropriate read value.
Hope the concept has clarity!
Let's explore SOA!
Krithika g
No comments:
Post a Comment