I would like to handle it. IMO it's a major flaw that it's not handled.
But...
In reality, no AS release with JBC 3.0 in it is going to come out for at
least a year. Probably longer than that. So, I'm concerned about focus
(particularly my own ;)). I'd be a lot more comfortable with an
iterative process on JBC 3.0 that does one thing at a time, in order of
priority. If a properly fleshed out merge API is higher priority than
MVCC and state transfer, or is somehow needed to do MVCC/state transfer,
then fine. But if this is something that's not going to really be
worked on for a long time, then I'd prefer not to elevate the design
discussion into something the whole dev team is focusing on now.
Bela Ban wrote:
You tell *us* ! Do you think that merging HTTP sessions is an issue ?
Does it happen all the time (probably not) ? If it happens, is this a
severe situation that needs to get handled ?
Brian Stansberry wrote:
> Bela Ban wrote:
>
> <snip/>
>
>>
>> I don't think we have thought hard enough about all use cases we
>> might implement, or at least consider for the design of the
>> interface. Maybe we need to brainstorm about this at our next
>> clustering conf call ?
>>
>
> Where is this on our priority list? Is this something we are going to
> actually do over the next 3-4 months? Or are we discussing something
> that's not going to happen for a long time?
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com