Hi,
40% of all time in TxManager.begin() is BAD !!
(So I'll leave this other minor problem until we get
this sorted out.)
It is not unusual that a lot of time is spent in
the transaction manager code, but:
- This should be in commit().
- The begin() should be extremely fast, as almost
nothing is done here.
So something is extremely wrong here.
Off the top of my head comes the following possible
things that may be slow:
- My use of SoftReference for holding onto cached
TxCapsule references for reuse. In case of memory
shortage, the while loop in TxManager.begin()
could run for some time while getting references
that were cleared by the the heap manager. That
should, however, only be a one-time problem. But
maybe SoftReference is simply slow?
- The TxCapsule.reUse() method. For Oracle
interoperability Aaron recently added a more generic
way of allocating Xids. Haven't really looked into
the new TxCapsule.createXid() methods. If this is
the problem, a simple replacement of the call to
createXid() with "new XidImpl()" should make it go
away (and break the Oracle XA driver).
What situation did you profile? The load test?
Do you have a per-line breakdown of processor time
spent in TxManager.begin()?
Do you have a per-method breakdown of processor
time spent in TxCapsule?
I have thought about reusing instances of TransactionImpl
and XidImpl, but decided against it as other code may
hold on to references of these, and (with sufficient bad
luck) try to use these after they have been reused.
FastTM should not be gone. While I think a lot about
how to better interoperate with other TMs, and how
changes to out fastTM could be made to make the
implementation of this smooth, I do not think that
I have changed anything the would make it slower.
Hope this helps to find the problem, otherwise
mail again.
Best Regards,
Ole Husgaard.
marc fleury wrote:
>
> That's a possibity... it also strikes me that that "fastTM" is gone, like
> gone :(
>
> I really believe we need a "realTM" and "fastTM". I suspect fastTM will be
> good for many many cases and it's overhead is key.
>
> (btw the 2nd and 3rd spot were for "setContextClassLoader" and
> "getContextClassLoader" and there I think that a pool of threads (per
> containerInvoker, with preset CL) will help.
>
> But clearly we can do better in the TM
>
> marc
>
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors
> |Sent: Saturday, October 28, 2000 10:00 AM
> |To: jBoss Developer
> |Subject: RE: [jBoss-Dev] Per-container transaction managers and
> |outgoingcalls
> |
> |
> |
> |
> |On Sat, 28 Oct 2000, marc fleury wrote:
> |
> |> |We have an old (currently very minor) problem, that
> |> |I would like to see fixed:
> |>
> |> we have other problems, namely optimizeIt says we spend 40% of
> |our time in
> |> Tx.begin() :P
> |
> |Something you could try is pooling the tx and xid implementations in
> |capsule. Now one instance is created per begin() and
> |capsule.reuse() creates just one xid per call (which goes into stuff like
> |System.properties on every call, this might cost you).
> |
> |Since these are heavily used, might wanna create a bunch of them at once,
> |instead one every call.
> |
> |-- Juha
> |
> |
> |
> |
