> So from my point of view, this is a bug.
> I don't think so. I think that this is spec. I know Weblogic does the same
> thing but they have a deployment option that solves this problem. I have
> also heard that other vendors supply this as well.
Now I'm quite upset. This behaviour should be spec? I can't think so. I do not believe
that specs tell to have two different value sets of one row inside of one transaction.
This would be a unrepeatable read, and that is what against transactions are made for!?
Also Philippe said that it should work in JOnAS. Did you ever try? ;-)
> >Another question is, why doA and doB both load the bean, you just could
> call doB with the EB as a parameter, so doB works on the same instance.
> Ain't that possible?
> Because method B can also be called directly by a client - code reuse, you
> know. So method B needs to be able to stand alone. That is why I don't want
> to change it transaction attribute.
That's bad design. Think over your accessability layers. A good design would be:
public SB.doA -- accessable from client, TX attributes; calls SB.implementationOfB
public SB.doB -- accessable from client, TX attributes; calls SB.implementationOfB
protected SB.implementationOfB -- this is the implementation of B (what is "doB" in
your code at the moment)., no TX attributes since this is not for clients.
Do you know what I mean? If you want to reuse code, make a reusable method out of it.
This method is called from either doB also from localDoB. The doX methods are for
calls from the client only, all reused code is encapsulated by implementationOfB.
HTH
Markus
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
