I've recently created a bunch of JIRAs for the simpler bits of the transaction integration work. However, there are some design issues that need discussion before the work can be codified into JIRAs... First up, distributed transactions. By that I mean ones involving business logic in more that one JVM. The simpler case of 'distributed' in the multiple resource manager sense already more or less works. The transaction system can run in two modes - jta, which does not support transactions spanning multiple jvms, or jts, which does.

Whilst the transaction control traffic always runs over CORBA, the business logic, typically EJB calls, may not. As far as I can tell there is as yet no spec or documentation on what we intend to support here or how tx context propagation and inflow is intended to work.

There is also the question of the extent to which we'll support tx use by external or legacy clients, be they Java or CORBA. i.e. client to server or server to older server, rather than between two AS7 instances. The ClientUserTransaction proxy arrangement in the old AS pre-dated the jts integration and never worked cleanly with it. We need to come up with something better. Who is handling the requirements and design for this in AS7?

While you and david will go on with requirement and design I can take care of AS7 management model for tx subsystem, going through and cleaning it a bit.

Hi, How things are going on these tasks? While you and david will go on with requirement and design I can take care of AS7 management model for tx subsystem, going through and cleaning it a bit. I have also to check if mgmt model is full supporting all the JTS config parameters. Maybe I'll ping you on this argument. Have you already created any Jiras about these arguments I should take over or just link? In case you haven't I'll create some to track my work. let me know if you have any concerns regards S. On 08/10/2011 02:43 PM, Jonathan Halliday wrote: > I've recently created a bunch of JIRAs for the simpler bits of the > transaction integration work. However, there are some design issues that > need discussion before the work can be codified into JIRAs... > > First up, distributed transactions. By that I mean ones involving > business logic in more that one JVM. The simpler case of 'distributed' > in the multiple resource manager sense already more or less works. > > The transaction system can run in two modes - jta, which does not > support transactions spanning multiple jvms, or jts, which does. > > Right now the AS decides which mode to boot depending on the presence of > an ORB, since that is used as the transport for distributed transaction > coordination. This is itself potentially a problem, since it's possible > that a user wants the ORB for non-transaction use only and does not want > to pay the performance penalty for running jts mode transactions that > never actually leave the local jvm. Even for local use the jts is > substantially slower than jta. So, you may want to consider allowing the > currently automated jta/jts choice to be overridden by the user. Another > interesting possibility is to use the module system to run two isolated > copies of the transaciton engine, one in jta and one in jts mode, then > allow applications to determine which they want and bind the JNDI > lookups accordingly. But I digress. > > There is an interdependency between the ORB and the transaction system, > in that the ORB runs a set of iniializers at startup and when the jts is > enabled these must include the jts service inializers. However, the > transaction system depends on the ORB... (AS7-1494) > > Assuming the user does require distributed transactions and the server > is running magically running with the jts enabled, we come to the > problem of distributed transaction boundary demarcation and context > propagation. > > Whilst the transaction control traffic always runs over CORBA, the > business logic, typically EJB calls, may not. As far as I can tell > there is as yet no spec or documentation on what we intend to support > here or how tx context propagation and inflow is intended to work. > > There is also the question of the extent to which we'll support tx use > by external or legacy clients, be they Java or CORBA. i.e. client to > server or server to older server, rather than between two AS7 instances. > The ClientUserTransaction proxy arrangement in the old AS pre-dated > the jts integration and never worked cleanly with it. We need to come up > with something better. > > Who is handling the requirements and design for this in AS7? > > Thanks > > Jonathan. > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

that's good enough for now. we aim to the most frequently used management options.

The AS management model is not intended to support all the JTS (or other parts of JBossTS) config options. There are over 100 of them in TS as a whole. Only the most commonly used ones are exposed. For the others there needs to be a general mechanism per AS7-1496.

AS7-1481, AS7-1494, AS7-1482, AS7-1491, AS7-1492 and AS7-1497 all need attention and should probably be assigned to the AS team. I've no idea how I wound up as the default assignee for an AS module when I'm not even on the AS team. Lack of better options at the time I guess.

Jonathan.

On 09/16/2011 06:50 AM, Stefano Maestri wrote: > Hi, > > How things are going on these tasks? > While you and david will go on with requirement and design I can take > care of AS7 management model for tx subsystem, going through and > cleaning it a bit. > I have also to check if mgmt model is full supporting all the JTS config > parameters. Maybe I'll ping you on this argument. > Have you already created any Jiras about these arguments I should take > over or just link? In case you haven't I'll create some to track my > work. > > let me know if you have any concerns > > regards > S. > On 08/10/2011 02:43 PM, Jonathan Halliday wrote: >> I've recently created a bunch of JIRAs for the simpler bits of the >> transaction integration work. However, there are some design issues >> that >> need discussion before the work can be codified into JIRAs... >> >> First up, distributed transactions. By that I mean ones involving >> business logic in more that one JVM. The simpler case of 'distributed' >> in the multiple resource manager sense already more or less works. >> >> The transaction system can run in two modes - jta, which does not >> support transactions spanning multiple jvms, or jts, which does. >> >> Right now the AS decides which mode to boot depending on the >> presence of >> an ORB, since that is used as the transport for distributed transaction >> coordination. This is itself potentially a problem, since it's >> possible >> that a user wants the ORB for non-transaction use only and does not >> want >> to pay the performance penalty for running jts mode transactions that >> never actually leave the local jvm. Even for local use the jts is >> substantially slower than jta. So, you may want to consider allowing >> the >> currently automated jta/jts choice to be overridden by the user. >> Another >> interesting possibility is to use the module system to run two isolated >> copies of the transaciton engine, one in jta and one in jts mode, then >> allow applications to determine which they want and bind the JNDI >> lookups accordingly. But I digress. >> >> There is an interdependency between the ORB and the transaction system, >> in that the ORB runs a set of iniializers at startup and when the >> jts is >> enabled these must include the jts service inializers. However, the >> transaction system depends on the ORB... (AS7-1494) >> >> Assuming the user does require distributed transactions and the server >> is running magically running with the jts enabled, we come to the >> problem of distributed transaction boundary demarcation and context >> propagation. >> >> Whilst the transaction control traffic always runs over CORBA, the >> business logic, typically EJB calls, may not. As far as I can tell >> there is as yet no spec or documentation on what we intend to support >> here or how tx context propagation and inflow is intended to work. >> >> There is also the question of the extent to which we'll support tx use >> by external or legacy clients, be they Java or CORBA. i.e. client to >> server or server to older server, rather than between two AS7 >> instances. >> The ClientUserTransaction proxy arrangement in the old AS pre-dated >> the jts integration and never worked cleanly with it. We need to >> come up >> with something better. >> >> Who is handling the requirements and design for this in AS7? >> >> Thanks >> >> Jonathan. >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

On 09/19/2011 07:44 AM, Jonathan Halliday wrote: > > The AS management model is not intended to support all the JTS (or other > parts of JBossTS) config options. There are over 100 of them in TS as a > whole. Only the most commonly used ones are exposed. For the others > there needs to be a general mechanism per AS7-1496. Note that general configuration mechanisms are not allowed in most circumstances. Either a property is important enough to be a first-class part of the schema, or it is not important enough to be a part of the supported configuration. That said, we will allow an unsupported ad-hoc configuration element. The element should be called "extension-properties", and the child elements should be property elements (e.g.<property name="foo" value="bar"/>). Note that unlike our formal schema, ad-hoc properties do NOT have any compatibility or functionality guarantees and are intended as a means by which we can deliver fixes which require configuration outside of the main schema. We can drop support for properties at any time; unrecognized properties are ignored. Here are some guidelines as to when to use what: 1. If the property is something that would be set in the default shipped configuration, it must be a first-class element, not an extension property. 2. If the property is something that is commonly configured or customized, it must be a first-class element, not an extension property. 3. If the property is something that the user should NOT generally be accessing or modifying, it should not be a first-class element. It MAY be added as an extension property as needed later on. I believe that this does mean that we will generally err on the side of having many configuration elements. Also, if we do plan to drop a first-class element, there needs to be a deprecation notice ahead of time; this should be planned well in advance.