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