[
https://issues.jboss.org/browse/AS7-1782?page=com.atlassian.jira.plugin.s...
]
Andrig Miller commented on AS7-1782:
------------------------------------
After thinking about this from my perspective, I believe what is exposed in the XML schema
represents the three management use cases:
1) The default transaction timeout (as specified above from with the default-timeout
attribute). Setting this lower or higher depending on the application can be important.
There is also a proprietary @TransactionTimeout annotation that developers can use to
override the default on a method basis within the application, but some developers may not
want to use that, since it is not a spec annotation.
2) The location of the transaction log, as users may want to move it from under the
distribution installation, to another location that is tuned for the performance needs of
the transaction log. Also, many organizations like to install the software in a read-only
file system, and have all the write locations on separate mount points/file systems. This
will be something we probably do in our benchmarking efforts, to isolate the I/O, and make
sure we are not creating an artificial bottleneck.
3) Finally, the transaction recovery environment configuration would the the only other
thing. This relates to the socket binding, status socket binding, and the recovery
listener. If the socket is used, then the socket binding and status socket binding have
to be set along with telling the recovery listener to listen on a socket (true), if the
uuid is used, then the socket bindings are unnecessary, and the recovery listener
doesn't listen on the socket. I believe the UUID setup is the default due to
OpenShift, which is fine. I'm not sure of any pros and cons between the two at this
point in time.
Provide management use cases and operations for the transaction
subsystem
-------------------------------------------------------------------------
Key: AS7-1782
URL:
https://issues.jboss.org/browse/AS7-1782
Project: Application Server 7
Issue Type: Feature Request
Components: Transactions
Reporter: Heiko Braun
Assignee: Stefano Maestri
Fix For: 7.1.0.Beta1
I cannot clearly identify all the use cases when looking at the current management
exposure:
{noformat}
[standalone@localhost:9999 /] /subsystem=transactions:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"default-timeout" => 300,
"enable-statistics" => false,
"enable-tsm-status" => false,
"node-identifier" => "1",
"object-store-path" => "tx-object-store",
"object-store-relative-to" => "jboss.server.data.dir",
"path" => "var",
"process-id-socket-binding" => undefined,
"process-id-socket-max-ports" => 10,
"process-id-uuid" => true,
"recovery-listener" => false,
"relative-to" => "jboss.server.data.dir",
"socket-binding" => "txn-recovery-environment",
"status-socket-binding" => "txn-status-manager"
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira