Hello Stephan,
> Which is now exactly the way to get this performance
> boost you were talking about.
> As I said, I do already have "Required" in my <trans-attribute>,
> so what else should I do to get such a longer termed
> transactions....?
With "Required" you only tell the container that it should execute that method within a
transaction. The problem is, you neither told him, when to open and close this
transaction. So
what he does is, to make an assumption about that, where it has to weighten security
agains
performance. In most cases, the container chooses security (as there is no option to
tell what's
more relevant), what leads to the fact, that the transaction will be closed long
before needed
(in the worst case, after every single setXXX).
So what you have to do is, to tell the container when to open and close a transaction.
With
"Required", you told him, that there has to be one transaction, nevertheless if it is
a new one
or an existing one. So if it is no problem for you that the container might use an
existing one
(this would be a question of security), you do not need to tell anything else for when
to begin a
transaction; the container will begin it, either long before your call, or (latest
possibility)
directly as a reaction to your method call.
More complicated is the end of the transaction. As I wrote before, the container has
to make an
assumption, when to close the transaction. As you did not tell the system when your
logical
transaction ends, it assumes that it ends directly after the setXXX method, and as a
result of
this, it closes the transaction (what leads to significant performance impact due to
the fact
that at transaction end, all changed data gets written [one single field in your
case], commited,
and re-retrieved (for sefety; the could be the possibility that another database user
changed
some othere fields, and this has to be reflected inside the container).
So you have two possibilities to tell the container, when to end the transaction:
a) Implicit
If you do not use setXXX on entity beans directly from your client but instead call a
SB's
method, this method is set to Required or RequiredNew, and this method does all that
setXXX in
sequence, the container will close the transaction not before the end of that SB's
method. In
that case, you have two performance benefits. The first is, that there will be no
transaction be
closed between two setXXX but only one at the end of the wrapper method. The second
is, you do
not suffer from slow network communication as SB and EB will run in the same VM.
b) Explicit
You can retrieve an user transaction from the transaction manager and call begin and
commit
methods against it. The container will execute you setXXX methods inside of this single
transaction then, what leads to the prevention of transaction closing between two
setXXX method
calls. This is done by very few code lines, which you can read out of the JOnAS
documentation. If
you were not able to find that few lines, let me know and I will post some. But keep
in mind that
still you have network transmssion for every single setXXX, begin and commit method
call.
> In other words: My client was just a very small programm,
> which only retrieved the Remote IF and then called the
> setXXX method and terminated. If I have a longer-running
> client, where are then the transaction dermarcations (that
> are to be set somehow by the container) ?
See above. In the implicit case, the SB's method demarcates the transaction
boundaries, in the
explicit case, your calls to begin and commit on the user transaction object will be
used to
demarcate transaction boundaries.
Markus
