Sverker Abrahamsson wrote:
Hi Chad, I'm not letting you off that easy... ;)
At first thought I came to the same conclusion as you, why waste a lot of resources on remote calls over RMI when it is between a web layer and ejb layer on the same app server, i.e. running in the same JVM. Of course everything should be using local interfaces and pass data by reference instead of by value.
However, the answer isn't that simple. Modern app servers like JBoss can detect if the call to the remote interface in fact is in the same jvm and then optimize it to go directly without having to pass through a socket and pass data by reference. Just like a call to a local interface (but there is probably some difference).
With local interfaces you couple the two objects quite tightly together, with remote interfaces you decouple them since they may be in the same jvm but doesn't have to be. A good example of that is if you use clustering, then you have to use remote interfaces.
You can easily prove this by provoking an Exception in a session bean when calling it from e.g. a Struts action in the same app server. You will see then that the stack trace will not contain any rmi entries. You should get more or less the same stacktrace if doing the same with local interface. Do the same from a remote client running in another jvm and you will see something compleatly different.
This is part of a RMI stacktrace:
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1845)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1769)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:51)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:552)
... 20 more
This is a stacktrace when the "remote" call is done in the same jvm:
at com.abrahamsson.portal.content.ContentServiceBean.getFileContentByFileMetadata(ContentServiceBean.java:462)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpljava:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:683)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:709)
at sun.reflect.GeneratedMethodAccessor99.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:97)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85) at $Proxy51.getFileContentByFileMetadata(Unknown Source)
Well, a lot of things happens but no RMI at least.
Hence, the only time it make sence to use local interface is the rare when you want to force the invoking client to be in the same jvm as the session bean. However, I don't see much benefit in doing that compared to just do a normal java reference.
Actually it isn't very rare at all, I (and actually most of my company) have the services deployed as local objects and just expose the service through a webservice. And in reality most people will use Session EJBs in the same JVM, if they want to change to remote, its a simple namespace property change (ejbViewType) and that's it (none of the interface names change).....it can't be that difficult to change that property can it ? :)
So, in my opinion the default view type should be remote and to answer my own question in the other mail, it doesn't make sence to have viewType="both" any longer.
/Sverker
----- Original Message ----- From: "Chad Brandon (JIRA)" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 16, 2005 10:52 PM
Subject: [Andromda-devel] AndroMDA/JIRA Closed: (HIB-76) Wrong default on @andromda.ejb.viewType
[ http://galaxy.andromda.org:8080/jira/browse/HIB-76?page=history ]
Chad Brandon closed HIB-76: ---------------------------
Assign To: Chad Brandon (was: Martin West) Resolution: Fixed Fix Version: 3.0RC1
I updated the docs
Wrong default on @andromda.ejb.viewType ---------------------------------------
Key: HIB-76 URL: http://galaxy.andromda.org:8080/jira/browse/HIB-76 Project: Hibernate Cartridge Type: Bug Versions: 3.0RC1 Reporter: Sverker Abrahamsson Assignee: Chad Brandon Priority: Minor Fix For: 3.0RC1
According the documentation the default view type of a session bean should be remote, which is also the default on the ejb cartridge. However, the default setting in hibernate cartridge is local view type.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://galaxy.andromda.org:8080/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel
