diff --git a/spring-integration-jdbc/src/main/resources/org/springframework/integration/jdbc/config/spring-integration-jdbc-2.0.xsd b/spring-integration-jdbc/src/main/resources/org/springframework/integration/jdbc/config/spring-integration-jdbc-2.0.xsd
index 2b90fd7366..30ec77b1c5 100644
--- a/spring-integration-jdbc/src/main/resources/org/springframework/integration/jdbc/config/spring-integration-jdbc-2.0.xsd
+++ b/spring-integration-jdbc/src/main/resources/org/springframework/integration/jdbc/config/spring-integration-jdbc-2.0.xsd
@@ -149,7 +149,7 @@
polled. In general the query can return multiple
rows, because
the result will be a List (of type determined by the row
- mapper).
+ mapper). The query can also be specified as a nested element.
@@ -184,7 +184,7 @@
An update query to execute when a message is
polled. If the poll is in a transaction then the
update will
- roll back if the transaction does.
+ roll back if the transaction does. The update can also be specified as a nested element.
@@ -243,7 +243,7 @@
referenced in named parameters, e.g. "INSERT into FOOS (ID,
NAME) values (:headers[business.key],
:payload)". More complex
- requirements can be implemented by
+ requirements can be implemented by specifying a sql-parameter-source-factory.
@@ -259,8 +259,7 @@
message can be
referenced in named parameters, e.g. "INSERT into FOOS (ID,
NAME) values (:headers[business.key],
- :payload)". More complex
- requirements can be implemented by
+ :payload)". The query can also be specified as a nested element.
diff --git a/src/docbkx/jdbc.xml b/src/docbkx/jdbc.xml
index 1652fa8236..f44f2272f5 100644
--- a/src/docbkx/jdbc.xml
+++ b/src/docbkx/jdbc.xml
@@ -66,15 +66,17 @@
]]>
- In this example the database is polled every 1000 milliseconds,
- and the update and select queries are both executed in the same
- transaction. The transaction manager configuration is not shown, but as
- long as it is aware of the data source then the poll is transactional. A
- common use case is for the downstream channels to be direct channels
- (the default), so that the endpoints are invoked in the same thread, and
- hence the same transaction. then if any of them fails, the transaction
- rolls back and the input data are reverted to their original
- state.
+
+ If a poller is not explicitly specified a default value will be used (and as per normal with Spring Integration can be defined as a top level bean)
+ In this example the database is polled every 1000
+ milliseconds, and the update and select queries are both executed in the
+ same transaction. The transaction manager configuration is not shown,
+ but as long as it is aware of the data source then the poll is
+ transactional. A common use case is for the downstream channels to be
+ direct channels (the default), so that the endpoints are invoked in the
+ same thread, and hence the same transaction. then if any of them fails,
+ the transaction rolls back and the input data are reverted to their
+ original state.
@@ -98,16 +100,78 @@
SqlParameterSourceFactory
- .
+ .
The outbound adapter requires a reference to either a DataSource or
a JdbcTemplate. It can also have a
SqlParameterSourceFactory injected to control the
- binding of incoming message to the query.
+ binding of incoming message to the query.
If the input channel is a direct channel then the outbound adapter
runs its query in the same thread, and therefor ethe same transaction (if
there is one) as the sender of the message.
+
+
+ Message Store
+
+ The JDBC module provides an implementation of the Spring Integration
+ MessageStore (important in the Claim Check pattern)
+ and MessageGroupStore (important in stateful
+ patterns like Aggregator) backed by a database. Both interfaces are
+ implemented by the JdbcMessageStore and there is also support for
+ configuring store instances in XML. For example:
+
+ ]]>
+
+ A JdbcTemplate can be specified instead of a
+ DataSource.
+
+ Other optional attributes are show in the next example:
+
+ ]]>Here we
+ have specified a LobHandler for dealing with
+ messages as large objects (e.g. often necessary if using Oracle) and a
+ prefix for the table names in the queries generated by the store. The
+ table name prefix defaults to "INT_".
+
+
+ Initializing the Database
+
+ Spring Integration ships with some sample scripts that can be used
+ to initialize a database. In the spring-integration-jdbc JAR file you
+ will find scripts in the
+ org.springframework.integration.jdbc package:
+ there is a create and a drop script example for a range of common
+ database platforms. A common way to use these scripts is to reference
+ them in a Spring
+ JDBC data source initializer. Note that the scripts are provided
+ as samples or specifications of the the required table and column names.
+ You may find that you need to enhance them for production use (e.g. with
+ index declarations).
+
+
+
+ Partitioning a Message Store
+
+ It is common to use a JdbcMessageStore as a
+ global store for a group of applications, or nodes in the same
+ application. To provide some portection against name clashes, and to
+ give control over the database meta-data configuration, the message
+ store allows the tables to be partitioned in two ways. One is to use
+ separate table names, by changing the prefix as described above, and the
+ other is to specify a "region" name for partitioning data within a
+ single table. An important use case for this is using the store to
+ manage persistent queues backing a Spring Integration channel. The
+ message data for a persistent channel is keyed in the store on the
+ channel name, so if the channel names are not globally unique then there
+ is the danger of channels picking up data that was not intended for
+ them. To avoid this the message store region can be used to keep data
+ separate for different physical channels that happen to have the same
+ logical name.
+
+