Hi, Terry Child and I started this discussion in castor-dev mailing list, but I think jboss-dev is more proper place for it. I wish someone who is close to jBoss TransactionManager and/or JNDI read the following and comment. TC = Terry Child, ON = Oleg Nitz TC> Is it possible to cache the TransactionManager in the JDO instead of TC> looking it up in JNDI every time, which is slow. I've just tried TC> the diff below and it seems to work but I don't know what TC> implications this might have. ON> In jBoss the transaction manager for the given bean container can be ON> configured in jboss.xml, so from the general point of view your ON> proposition doesn't go. TC> I don't know enough about JBoss and MBeans to fully understand TC> this - please bare with me. Is it the case that different bean TC> containers can each have a separate TM specified, but that the TC> MBeans apply across the whole server, so that in theory stateless TC> session beans and stateful ones could be using different TMs and TC> the only way for an MBean to know this is to use JNDI to look TC> the TM up 'on the fly'. Well, I am not sure that this is really possible. ON> Could you measure the speed improvement that is gained due to your ON> change? TC> I was running JBoss inside OptimizeIt. The JNDI lookup in TC> JDO.getDatabase() was taking 14% of the time. If it's cached the TC> time is insignificant. Infact most of the time was spent doing TC> JNDI lookups either for minerva or castor. Only 2% of the time was TC> spent executing application code :( :( If JNDI lookup takes so much time, I have to reconsider my principle to lookup resource factories and resources on each method invocation. Is it really so hard to provide fast lookup for bean's JNDI context? The bean's JNDI context is fully defined by ejb-jar.xml, so let's have a HashMap of all JNDI names/entries for each bean, fill it on deployment, and lookup in it - it will work super-fast. Best regards, Oleg
