"urisherman" wrote : > You're not *deploying* the cache from an EJB, right? | What do you mean by "*deploying*"? Creating it and starting it? | Lets say I won't do that from an EJB, that's not the issue. |
Yes, deploying means instantiating, creating and starting the service. anonymous wrote : | > It should be a separate deployment, either standalone or packaged with | > the ejb jar(s) in an ear or a sar. | It won't be standalone, it is intended to "live" inside our application. What do you mean by packaged with the ejb jars? The cache implementation is provided by u guys, it's in the server's lib directory. I use it inside my application, which is an ear that includes a bunch of ejb jars and wars. | Having a couple jars in lib doesn't mean we provide a cache service. It means we provide classes you can use to deploy a cache service by deploying a -service.xml file. You need to do that, unless you plan to hijack one of the existing running caches that the AS uses for http session and EJB3 replication. Using those caches for other purposes is not good practice. anonymous wrote : | Even if I don't deploy the cache from within an ejb (assuming "deploy"="create and start"), when I manipulate it from within an ejb the cache has to replicate itself, thus creating/dispatching a call to another thread (if working with async replication), or issue network io calls from the containers thread (if working with sync replication). Async replication doesn't mean your EJB creates a thread or "calls" a thread. Your ejb call puts an object (a replication message) in a queue, that's all. The fact that another thread is polling that queue and doing things with the objects found there is not a function of your EJB. The fact that you're using async replication means your EJB is not concerned with the object after it puts it in the queue. Re: synchronous and network io, if you set down_thread="false" in every protocol in the JGroups config, yes, your EJB thread will end up doing network io. I don't think that's a big issue; hard for me to see how network io isn't involved in common things like session beans putting messages in a JMS queue, or session beans making remote calls to other EJBs. If this is a concern for you, leave one of the protocols set to down_thread="true" and your EJB thread will no longer be the one doing the network io. BTW, clustered SFSB's and entity beans in JBoss all end up making JGroups calls to keep state consistent across the cluster. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987983#3987983 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987983 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
