anonymous wrote : 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. Deploying a -service.xml file? We are using WLS9.2/WLS8.1 not JBoss.....
anonymous wrote : 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. Fair enough, I understand. anonymous wrote : 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. The problem isn't network io nor thread/synchronization management in general, the problem is someone else doing it that's not the app server. of course the application server messes around with all that all the time, that's exactly why no one else *should* according to the spec. I think u didn't understand me because I failed to mention (or only mentioned it in my very first post) we aren't running on JBossCache on JBoss (in that case I wouldn't have any thoughts about the issue, AFAIC JBossCache is part of JBoss appserver) but rather integarting it into WLS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988068#3988068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988068 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
