[esb-issues] [JBoss JIRA] Closed: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd

[Tom Cunningham (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]

Tom Cunningham closed JBESB-1071.
---------------------------------


> SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBESB-1071
>                 URL: http://jira.jboss.com/jira/browse/JBESB-1071
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Rosetta
>    Affects Versions: 4.2, 4.2.1
>         Environment: OSX-10.4.10
> Dual 2GHz PowerPC G5, 3GB
>            Reporter: Bernhard Gass
>         Assigned To: Tom Cunningham
>             Fix For: 4.2.1
>
>
> SqlTableGatewayListener auto created a prepared sql statement from the information given in the *-esb.xml file defining your services. A where condition is supported in the code
> SqlTableGatewayListener - Line 344
> ListenerTagNames - Line 111
> but 'whereCondition' or 'where-condition' is not supported in jbossesb-1.0.1.xsd.
> Asessment:
> If my understanding is correct the generated prepared statement is called for every pull, but only one message is processed. 
> Every fetch loads ALL messages from the DB every cycle which leads to a problem specially when the source database has many rows. A static where clause can solve some of the above, but most likeley a parameterized 'where clause' is desireable (which leads to the question where the parameters come from).
> Additional considerations:
> - Processing speed can be improved considerably by fetching several rows and  deliver them for processing one by one or better process them in batches all together (given the business case allows that).
> - Some mechanism is needed to parameterize the fetching mechanism. A rudimentary mechanism can be realized using a plain 'where' clause
> - In a production scenario additional issues play a role. 
>    - Messages most of the times have a sequence they need to be processed in.
>    - A specific business case might or might not allow gaps in the sequence of transaction id's. A sequence of transaction id's without gaps often is used to assure no messages are missing.
>    - Even using something like an Oracle sequence is not a guaranty for a sequence witout gaps (sequence gaps can e.g. occure after a Oracle CPU flush).
>     - It might not be possible or desireable to change the table containing the payload. In that case you need a second table containing  'transactions id's', 'prcessing status', 'processing instructions' etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira