[EJB 3.0] - Re: circular references
by robert.geisler
you are always very fast, jaikiran :)
god bless you ; )
"jaikiran" wrote :
| As far as i know, it's not possible to do this at class level.
|
to do what at class level? to @IgnoreDependency?
"jaikiran" wrote :
| Can you please provide a bit more details about the issue you are running into? Preferably with the relevant code and the logs.
|
our problem is, that we do not want to use dependency injection on some stateless beans, because we want to lazy lookup a few ejbs just when we really use them. earlier we achieved that through private getters that looked up the ejbs by their local jndi name (@LocalBinding). but we cannot use this pattern anymore, because we want our .ear to be portable to WebSphereAS (WAS doesnt have such a thing like @LocalBinding, but requires a "ejblocal:/" prefix for local business interfaces).
thats why we put class level @EJBs annotation on that stateless beans and use getters that lookup the ejbs by the logical name declared in @EJB.
we thought this way we may avoid injection of ejbs that mostly never will get used. but when we now deploy our .ear on JBoss, JBoss complains about circular references (as we would use dependency injection).
please have a look at the simplified code below.
here is one statless bean that declares dependency on class level. it dont use injection, but lazy lookup the referenced ejb through getter-method.
@Stateless(name = "StatlessOne")
| @Local(value = StatlessOne.class)
| @EJBs(value = { //
| @EJB(name = "StatlessTwo", beanName = "StatlessTwo", beanInterface = StatlessTwo.class)
| })
| public class StatlessOneBean implements StatlessOne {
| @Resource
| private SessionContext sessionContext;
|
| // lookup "on-demand"
| public StatlessTwo getStatlessTwo() {
| return (StatlessTwo) sessionContext.lookup("java:comp/env/" + "StatlessTwo";
| }
|
| ...
|
| }
here is the corresponding ejb. the first ejb gets injected, beause the second one will always use the first ejb.
@Stateless(name = "StatlessTwo")
| @Local(value = StatlessTwo.class)
| public class StatlessTwoBean implements StatlessTwo {
| @Resource
| private SessionContext sessionContext;
|
| @EJB(beanName = "StatlessOne") // lookup "always"
| private StatlessOne statlessOne;
|
| public boolean hasStatlessOne() {
| return (statlessOne != null);
| }
|
| ...
|
| }
and thats the errors, JBoss loggs when we deploy our .ear:
2009-06-29 13:23:15,054 INFO [org.jboss.ejb3.EJB3Deployer] Starting java:comp multiplexer
| ...
| // all ejbs got deployed without errors:
| INFO [org.jboss.ejb3.EJB3Deployer] Deployed: file:/...MyServer.ear-contents/StatelessOne.jar
| INFO [org.jboss.ejb3.EJB3Deployer] Deployed: file:/...MyServer.ear-contents/StatelessTwo.jar
| ...
| INFO [org.jboss.deployment.EARDeployer] Started J2EE application: file:/...MyServer.ear
| // AFTER deployment these erros are shown:
| ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:
|
| --- MBeans waiting for other MBeans ---
| ObjectName: jboss.j2ee:ear=MyServer.ear,jar=StatelessTwo.jar,name=StatelessTwo,service=EJB3
| State: NOTYETINSTALLED
| I Depend On:
| jboss.j2ee:ear=AfpsServer.ear,jar=StatelessOne.jar,name=StatelessOne,service=EJB3
|
| ObjectName: jboss.j2ee:ear=MyServer.ear,jar=StatelessOne.jar,name=StatelessOne,service=EJB3
| State: NOTYETINSTALLED
| I Depend On:
| jboss.j2ee:ear=MyServer.ear,jar=StatelessTwo.jar,name=StatelessTwo,service=EJB3
|
| ...
|
| INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [4.2.2.GA [...] Started [...]
maybe i missunterstood the @EJB annotation at all?
i thought, that * @EJB on class level just declares a dependency and the application server puts the corresponding ejb into the local jndi context, while * @EJB on field level injects an instance of the corresponding ejb into the fieldam i wrong?
regards robert
ps:
its complicated for me to explain all these things in english.
so i hope you will forgive me if i confuse you O: )
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240786#4240786
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240786
16 years, 9 months
[Clustering/JBoss] - Implementation JMS Failover (Clustring) In jBoss 4.2.3 GA
by sjunejo
Hi All,
I search through internet and this forum but couldn't find a complete guid through which I can even start. Some of the documents mention on 'Home Page' of jBoss Clustring talking about some cluster-service.xml and cluster folder in my deploy directiry but i dont have anything here.....can anyone please provide me some inof on how to setup a clusterw ith four jboss server instances. I am attaching a failover diagram in this post for better understanding.
[img]http://img37.imageshack.us/i/ideak.png/%5D%5BIMG%5Dhttp://img37.imageshack.us/img37/962/ideak.th.png[/img]
Server 1 and Server 2 will hold my Web Application and possible targets of each other in case of failure where Server 3 and Server 4 will hold my Message MDB and possible targets for each other in case of failure. All three Queues should be distributed destinations cluster wide.
FYI: I have already implemeted the same using WebLogic 10.3.
Is it going to be simillar using jBoss.
Your help will be appreciated.
Thanks & Regards,
Sheeraz
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240774#4240774
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240774
16 years, 9 months
[JBoss Cache: Core Edition] - Re: How does JBoss Cache perform with high (15-20) number of
by bela＠jboss.com
So I'm assuming we have a 20 node cluster, and every node sends 25KBytes/sec (25 KBytes == 200KBits).
When using UDP, every node sends 1 multicast packet, to be received by every other node. So you scenario above (15x15) doesn't apply.
When using TCP, every node sends a message N-1 (19) times, so your scenario *does* apply in this case.
With respect to network bandwidth, sending is not the issue because every node has a full duplex line to the switch.
However, when receiving, a line from the switch to a node has to be shared between 19 (N-1) instances. In other words, every node can receive concurrent traffic from the 19 other nodes.
So if you have a 1GB switch, then the effective rate / node is 1000MBits/19 = 52MBits = 52'000KBits = 6'500KBytes /sec. That 260 times more that you need !
So this is peanuts traffic-wise. The bottleneck might lie somewhere else, namely in the data: when everyone replicates its date to everybody else, every node has to store DATA * 20 on average. So if every node has data of 1MB, then the avg data size on a node is 20MB. This is fine, but of course not scalable if (1) your avg data size increases or (2) your cluster size increases.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240771#4240771
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240771
16 years, 9 months
[EJB 3.0] - Re: flushing EJB3 for use with EJB2.1
by robert.geisler
some update here...
we are almost done with our ejb2.1-to-ejb3.0-migration. but some weeks ago we have been in deep doo-doo(?). the problem was the performance of the ejb3 entity manager when it came to persist, update and remove very, very much entities in one long transaction (long >= 2 minutes).
we tried to log and debug the data layer and finally recognized, that performance of calling entity manager's cud methods (create, update, delete) slows down more and more the longer the transaction is running.
our sample transaction took about 8 minutes before ejb 3.0. after migration, it always met the transaction timeout (>= 30 minutes (for testing)!!) and we had no idea what could be the reason. question: Hibernate? well, we tried another persistence provider (thanks JBoss for easy changing the persistence provider! :) *noirony*), EclipseLink, and got it done in about 10 minutes. answer: Hibernate!?
kind of strange behaviour, we thought, but we were able to find a solution: we now dont call flush after single cud methods, but call flush and clear on entity manager just before our data layer returns. that improved our performance extremly; after applying the new pattern, our sample transaction took about 2 minutes (Hibernate! EclipseLink now needs about 22 minutes ;)).
so far...
i hope, our experiments and experience may help others, too.
regards
robert
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240770#4240770
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240770
16 years, 9 months