[jbossts-issues] [JBoss JIRA] (JBTM-1644) Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?)

Michael Musgrove (JIRA) jira-events at lists.jboss.org
Sat May 18 18:47:06 EDT 2013


     [ https://issues.jboss.org/browse/JBTM-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-1644:
-----------------------------------

    Attachment: use-postgresql.patch


I tested using a modified version of the jta crash rec quickstart (http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/jta-crash-rec/) running on an instance of the wildfly application server. The modification is to use postgresql as the database and to halt the VM after committing the JMS resource but just before committing the database resource. To facilitate recovery from another node you must use network accessible addresses for the database, i.e. configure postgresql to listen on the same IP address as the ServerName in the datasource configuration (i.e. localhost is no good). This restriction does not apply to the application server which can be started on localhost.

Then I moved the file based object store to another host and started another application server with the same version and config. Identical configs probably isn't necessary as long as the transaction and datasources subsystems are configured in the same way, in particular any JNDI datasources needing recovery must be present. If application deployments define their own datasources (which is the case with the jta crash rec example) then these applications must also be deployed on the new server. The transaction config includes a node id which must be the same as the failed host. It is imperative that only one server is running with this node id (i.e. do not restart the failed node with the same id whenever you plan to recover on a different host). This restriction guarantees that different recovery systems do not recover the same transactions. We also mandate that we have one recovery system per object store. In the future we may relax this restriction to allow different nodes to share stores.

Note that you can avoid copying the file based object store if you use a JDBC object store running, for simplicity, on the same postgresql database. To do this you would need to configure a non XA datasource (by updating the transactions subsystem properties use-jdbc-store and jdbc-store-datasource with this datasource JNDI name or just add the config directly to the transactions subsystem definition in standalone-full.xml, eg <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectStoreDS"/> If you plan to restart the old node using the same store we recommend that you use different table names. 

Now recovery will eventually commit the database update which you can verify by polling the quickstart db table:
{noformat}
-bash-4.2$  psql -h a.b.c.d -U sa jta-quickstart-database
psql (9.1.6)
Type "help" for help.

jta-quickstart-database=> select (name,value) from kvpair;
...
{noformat}
The attached patch contains the modification to commit the JMS datasource before the database and includes the datasource definition for using postgresql (jta-crash-rec-quickstart-ds.xml - you will need to change ServerName from a.b.c.d to an IP address that is accessible from both hosts in your test configuration).
                
> Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-1644
>                 URL: https://issues.jboss.org/browse/JBTM-1644
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Demonstrator, Documentation
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>            Priority: Critical
>             Fix For: 5.0.0.M3
>
>         Attachments: use-postgresql.patch
>
>
> Please can you document any restrictions (stating none if there are none). How to configure the recovery manager (e.g. specific node id, not *). Considerations a user should have (not to connect more than one recovery manager to the same store at once, suggestions for how to restrict that - maybe object store specific?)
> Object store specific information, e.g. if you are using filesystem/hornetq/jdbc do any of them ensure that only one process is accessing at the same time?
> A simple quickstart demonstrating how to use (maybe JDBC object store inside AS7 would be most appropriate) would be useful.
> Does IP address play a role, are there any other restrictions?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the jbossts-issues mailing list