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. +
+