[JBoss JIRA] Created: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
3:02 a.m.
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: Mark Little
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).
--
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
3:04 a.m.
New subject: [JBoss JIRA] Updated: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Bernhard Gass updated JBESB-1071:
---------------------------------
Description:
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.
was:
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).
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: Mark Little
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
11:19 a.m.
New subject: [JBoss JIRA] Assigned: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Mark Little reassigned JBESB-1071:
----------------------------------
Assignee: Tom Fennelly (was: Mark Little)
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 Fennelly
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
10:43 a.m.
New subject: [JBoss JIRA] Updated: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Mark Little updated JBESB-1071:
-------------------------------
Fix Version/s: 4.2.1
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 Fennelly
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
8 p.m.
New subject: [JBoss JIRA] Assigned: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Kevin Conner reassigned JBESB-1071:
-----------------------------------
Assignee: Tom Cunningham (was: Tom Fennelly)
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
2:04 p.m.
New subject: [JBoss JIRA] Assigned: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Mark Little reassigned JBESB-1071:
----------------------------------
Assignee: Tom Fennelly (was: Tom Cunningham)
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 Fennelly
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
3:23 p.m.
New subject: [JBoss JIRA] Assigned: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Mark Little reassigned JBESB-1071:
----------------------------------
Assignee: Tom Cunningham (was: Tom Fennelly)
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
11:15 p.m.
New subject: [JBoss JIRA] Work started: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Work on JBESB-1071 started by Tom Cunningham.
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
10:38 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=comments#action_12380361 ]
Tom Fennelly commented on JBESB-1071:
-------------------------------------
Just as a matter of interest... could this be supported in the existing codebase by adding
the where clause as a <property> on the listener config? I mean this as a short
term solution for Bernard while it's being sorted out properly.
To add it as a property, just check the code and see what attribute name is used to query
the where clause from the ConfigTree. Then use that name as the <property> name
attribute, with the where clause in the <property> value.
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
5:37 p.m.
New subject: [JBoss JIRA] Resolved: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ http://jira.jboss.com/jira/browse/JBESB-1071?page=all ]
Tom Cunningham resolved JBESB-1071.
-----------------------------------
Resolution: Done
Added support for where-condition and order-by, and added them to the
helloworld_sql_action quickstart. To keep things consistent, these have been added
to the <sql-message-filter> tag, which contains all of the other schema-related
attributes (status-column, tablename, message-id-column, etc). The order-by should
allow messages to be processed in the order that is desired.
A lot of the other feedback here is good but probably belongs at a higher level. I
would think that batch processing of messages and guarantee of the entire batch would be
higher-level abstractions that would be pertinent to any transport (file, ftp, sql, etc)
and not just SQL. Please file an additional bug for this - the where condition and
batch processing aren't really related.
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
5:37 p.m.
New subject: [JBoss JIRA] Closed: (JBESB-1071) SqlTableGatewayListener code supports 'where' clause, but it is missing in jbossesb-1.0.1.xsd
[ 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
6112
days inactive
6124
days old
10 comments
5 participants
participants (5)
-
Bernhard Gass (JIRA) -
Kevin Conner (JIRA)
-
Mark Little (JIRA)
-
Tom Cunningham (JIRA)
-
Tom Fennelly (JIRA)