[jboss-as7-dev] TX subsystem management use cases

[Brian Stansberry]

On 6/1/11 6:46 PM, Jonathan Halliday wrote:
>
> On 05/31/2011 01:28 PM, Brian Stansberry wrote:
>
>> Couple questions to see if we can future-proof the management
>> configuration of the AS's transactions subsystem:
>>
>> 1) How will these multiple transactions managers be uniquely identified?
>> A simple string name?
>
> Possibly, but no promises at this stage.
>
>> 2) How will the various configuration components you have now map to
>> these multiple transaction managers? You've got a CoreEnvironmentBean,
>> CoordinatorEnvironmentBean, ObjectStoreEnvironmentBean,
>> RecoveryEnvironmentBean.
>
> Actually there are 12 more such types in the codebase, but what you
> don't know won't hurt you. for now. probably. Of the 180+ config options
> in JBossTS, only a handful are actually exposed to AS users. The AS
> internally overrides a handful more from the defaults that JBossTS
> ships. The rest use default values.
>
> Will each transaction manager have a set of
>> those, or will some be common across transaction managers?
>
> There are already multiple instances of some bean types used internally,
> particularly for store config.
>
> As for future versions, what makes you think any of those will still
> exist? :-)
>
> You can't take anything as fixed, we're making a new major version here
> and will cheerfully slaughter any sacred cows that get in our way.
> Perhaps in the future all the internal components of the transaction
> system will be native MSC modules and services.
>
> My gut feeling is the system will be flexible enough to allow multiple
> high level component instances to be layered onto either shared or
> individual lower level component instances, but I may change my mind
> tomorrow. Or even right after coffee.
>
> In short, future-proofing attempts would be a waste of time.
>

Thanks; that's essentially what I wanted to find out, but didn't want to 
play 20 questions if it wasn't a waste of time.

> On the other hand, making the new HornetQ journal based objectstore
> implementation a user configurable option would have a huge performance
> benefit for some scenarios. Likewise making the JTA/JTS choice
> selectable - just having an ORB present does not necessarily mean a user
> needs distributed tx and the associated performance penalty for all tx.
>

Tell me how you wanted these configured and we'll see if we can get them in.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat