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

[Jonathan Halliday]

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.

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.

Put the limited time available into working on things that will have a 
benefit, not things that may.

yours opinionatedly

Jonathan.

-- 
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod 
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons 
(USA) and Brendan Lane (Ireland).