[jbossts-issues] [JBoss JIRA] Commented: (JBTM-390) add ability to run DTF tests locally without DTF server

[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday commented on JBTM-390: ---------------------------------------- re: the jdbc tests. Most tests use two db accounts. They get the connection info from a properties file, which is machine (testnode) specific. They construct table and other identifier names using the username from that file. By giving each node its own pair of db accounts, they therefore don't interfere with eachother when running tests simultaneously. That's a surprisingly common case, as it's typical to initiate a test run spanning multiple nodes (e.g. different O/S). On the up side this is flexible enough that we can do clever stuff like splitting a test over two nodes and having them actually use the same accounts, to simulate e.g. a distributed tx with nodes connecting to a shared db. On the down side, we need lots of db accounts set up and can use only test nodes that have been configured. This is ok for the DTF, which has a stable set of 10 nodes. It's a pain for hudson, which has lots more. Therefore, the following changes will be made: 1) Table and other identifier names will be done through a utility function to provide a single point where we can change the strategy. Initially the change will be: include the node name (hostname, with some munging because e.g. '-' is ok in hostnames but not some db's identifiers) in the table name, in addition to the username. This actually changes the semantics of the tests somewhat, but only for multinode cases like the one described above, which we don't currently run anyhow. 2) The mechanism for reading properties file will be extended so that if it does not find a properties file for the named host on which it's running, it will use a default one. Thus DTF nodes can remain unchanged, whilst hudson slave nodes will share a single pair of db accounts but not conflict because of the table naming strategy change. That leaves the problem of getting the db drivers in the first place, which is for another comment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira