Nigel,
thanks for clarifying this... sounds much better now, and sorry for being so explicit (I maybe should have slept over it before pressing the send button :-)
Rüdiger
On 2012-07-09, at 18:22, Nigel Deakin wrote:
> On 03/07/2012 08:24, Rüdiger zu Dohna wrote:
>> On 2012-06-28, at 13:05, Nigel Deakin wrote:
>>> As I said, it was to make it easy to prevent programmers from accidentally writing bad code though this isn't
>>> something I feel strongly about. Your remark that it's not the spec's job to babysit application writers is a valid
>>> one. Does anyone else have any comments on this?
>>
>> Only skimming these mails, I don't understand all of it, but this one sounds quite patronizing to me. Developers are
>> not babies, but they are under enormous pressure to get things done, leaving only time to learn what they actually
>> need. So the default behavior should always be as safe as possible... and this is especially true when it comes to
>> multi-threaded code: Nothing is worse than code that passes all of your unit and integration tests and then
>> sporadically fails without any apparent reason in production. If you'd need to study the spec carefully to find out
>> what's wrong, the spec is not doing it's job!
>>
>> Yes, I do feel strongly about this!
>
> Thank you for your comments!
>
> My proposals (that (1) we prevent applications accessing a message object during the period after it was sent and before
> the completion callback was invoked, and that (2) we prevent applications that perform an async send from sending the
> same message object a second time) were designed to prevent developers from accidentally writing code that might not
> always work.
>
> I think it is definitely a goal of JMS (and Java EE in general) to avoid the need for developers to become experts in
> multi-threaded programming. That's why, for example, we specify that the MessageListener associated with a consumer will
> only be called from one thread at a time: to avoid the need for the developer to make it threadsafe.
>
> On the other hand JMS isn't totally foolproof - although applications are not allowed to use the resources of a session
> in two threads at the same time, JMS providers are not required to detect this and throw an exception. This can be
> thought of as an example of JMS not "babysitting" the developer.
>
> So there's a judgement to be made. I would suggest that JMS should try and prevent developers writing incorrect code so
> long as (a) enforcing any restrictions does not impose an unreasonable burden (e.g. on performance) on JMS providers and
> (b) this does not have the side-effect of unreasonably preventing developers from doing legitimate things.
>
> My feeling is that the restrictions (1 and 2) I am proposing are simple for providers to enforce. They require the
> provider to store extra information in the message object to define whether, say, its headers can be accessed. However
> they do not require the provider to check what thread is being used to call a method, which might be more expensive.
>
> I also think that preventing applications that perform an "async send" from sending the same message object a second
> time is not an unreasonable restriction in developers. Although JMS currently allows applications that perform a sync
> send to send the same object a second time (and this will continue to be allowed) this is an obscure feature, and
> prohibiting it in the case of applications that perform an "async send" will not in practice affect developers -
> especially as there is a simple workaround.
>
> Any more views?
>
> Nigel