More read-mostly pattern & JNDI Lookup.

Hi all,
I'm still having problems with the read mostly pattern implementation.
I get the following:
weblogic.utils.AssertionError: ***** ASSERTION FAILED ***** - with nested exception:
[javax.naming.NameNotFoundException: Unable to resolve UserRO. Resolved: '' Unresolved:'UserRO'
; re
maining name '']
Although the bean is defined correctly. i.e: if I don't use the <invalidate-taget>,
everything works, I can read from the RO bean, I can write to the RW bean but
of course, I can't see the changes.
Now, one more path comes to my mind. Does my Entity bean have to implement the
Remote interface? All my EB are local, thus "Bean" is reachable by "BeanRef" locally
in the container.
Any suggestions? Can I make WL to lookup the local interface for the Invalidation
target? What am I doing wrong??
Regards,
Gerard.

Pundits/Gurus == Any recommendation on this topic?
Thanks, ~vk

Similar Messages

Read-mostly pattern in Toplink?

Hello:
I am using Toplink 10g (9.0.4) with Weblogic 8.1, and am using EJB 2.0 CMP entity beans. For performance reasons, I have a Read-Only bean and a Read-Write bean, both using the same RDBMS tables for persistence. I would like to implement a 'Read-mostly' pattern, where I would use the Read-Only bean for reads and the Read-Write bean for writes (duh!). If I used Weblogic's CMP, I can set the Read-Write EJB to 'invalidate' it's Read-Only counterpart whenever any changes to its persistent field are saved to the database - this is done by an entry in the weblogic-ejb-jar.xml descriptor. This forces the data for the Read-only bean to be reread from the database on the next call. Since Toplink is taking care of CMP, putting this entry in my weblogic-ejb-jar.xml file obviously does nothing. Is there any way to implement this pattern using TopLink? Thanks for any help.

First, thanks for the reply.
I do realize I don't explicitly need to have two beans. Let me fill in the gaps a bit:
I'm trying to wring out every ounce of performance from my application. Using a ReadOnly Entity bean allows me to better control what TopLink registers when I enter a transaction. I've noticed that even for straight reads, TopLink registers every object that the read/write entity bean 'touches' during a method call, and then checks all of these objects to see if they changed before committing the transaction. Needless to say, this is unnecessary, and significantly slows down the application. When I use a ReadOnly entity bean, this object registration doesn't happen.
So, to be more specific, is there any way I can set a method on a Read/write entity bean to 'ReadOnly', so it doesn't unnecessarily register all the objects? I cannot figure out a way to do this, so I've used a ReadOnly bean in combination with a ReadWrite bean to get around this performance bottleneck.
Thanks again for your time.
- Robert Benkovitz

Read-mostly pattern & EJB-QL question when using Weblogic 8.1

I want to use the same implementation of an CMP entity bean for the
read-mostly pattern in BEA Weblogic 8.1 (means for the reader and the
writer class).
Therefore my ejb-jar.xml contains the following statements:
<ejb-name>MyBeanReadOnly</ejb-name>
<local-home>mypackage.MyBeanLocalHome</local-home>
<ejb-name>MyBean</ejb-name>
<local-home>mypackage.MyBeanLocalHome</local-home>
The weblogic-ejb-jar.xml and weblogic-cmp-rdbms-jar.xml have the proper
changes.
I can deploy this bean & for the corresponding session bean binding
and calling methods works for the (virtual) read-only and read-write
entity beans.
When we are using Xdoclet and ejb.finder methods e.g.
@ejb.finder
signature="java.util.Collection findAllValid(java.util.Date date)"
result-type-mapping="Local"
query="SELECT DISTINCT OBJECT(u) FROM MYTABLE AS u
WHERE (?1 >= u.validFrom) AND ((u.validUntil IS NULL)
OR (?1 <= u.validUntil))"
the compilation and packaging runs well (as usual).
During the deploy to Weblogic 8.1 we get errors, because the
implementation of MyBeanReadOnly's findAllValid(...) should return
objects of type MyBeanReadOnly instead of MyBean.
Is there a way to solve this problem
- and not write seperate reader and writer classes like
the Weblogic 5.1 sample implementation?
- and not use the CMP optimistic locking?
Thanks for any further information.
Wolfgang

surya jeedigunta wrote:
We are using Weblogic 8.1 SP2 and our Oracle Database is of version 9.2.0.5.
I created user ID 'testa' in the database which owns all the objects.
I created another userID 'testb' which has privileges to read, modify and delete data from tables owned by testa.
I created public synonyms for all the objects owned by testa.
I set the userid 'testb' and password in weblogic administrator window and set the same in reg.xml file also.
Now when I tried to install the application, I got the following errors:
BEGINNING INSTALLATION
START INSTALLING FORMS SECTION
Installing Form ./dataform/EventHistory.xml...<ErrorStack>
<Error>
<Code>FORM_045</Code>
<Msg><![CDATA[ Form "Form" schema lacks some required columns:
Field=ID column=ID does not exist in table=QSTForm
Field=Name column=Name does not exist in table=QSTForm
Field=Version column=Version does not exist in table=QSTForm
Field=Content column=Content does not exist in table=QSTForm
Field=LastModified column=LastModified does not exist in table=QSTForm ]]></Msg>
</Error>
<Error>
<Code>FORM_7</Code>
<Msg><![CDATA[ Failed to bind FDT columns, exception com.quovadx
.bpms.core.CWException: (FORM_045) Form "Form" schema lacks some required column
s:
Field=ID column=ID does not exist in table=QSTForm
Field=Name column=Name does not exist in table=QSTForm
Field=Version column=Version does not exist in table=QSTForm
Field=Content column=Content does not exist in table=QSTForm
Field=LastModified column=LastModified does not exist in table=QSTForm ]]></Msg>
</Error>
My question is :
does weblogic 8.1 works when I use public synonyms and user id other than the schema owner ID?
I would appreciate if somebody could help me with this.
Thank YouHi. I wish I could help you more, but so far, from what symptoms you've shown us,
this is a purely internal Oracle issue to do with what your second user sees or
can access. The fact that the user is logging in via JDBC or through WebLogic is
irrelevant.
Joe

Cluster-wide invalidation using read-mostly pattern

Hello,
I have a qeustion around the use of the read-mostly Entity Beans pattern with implicit invalidation (through specifying the read-only EJB name in the <invalidation-target> element of the read-write bean's DD).
When an update occurs in the read-write bean, is invalidation propogated to all nodes in a cluster, thereby forcing a ejbLoad() on the next invocation of instance of the read-only bean?
I was reasonably certain that this was the case. It has been a while but my memory is that even in 6.1, invalidation using the CachingHome interface (obiovusly not quite the same thing, but surely close) performed a cluster-wide invalidation. Unfortuantely I don't have a cluster lying around to knock up a quick test case at the moment.
The reason for me raising the question is that if you search for "read-mostly" on dev2dev you will find a recent article from Dmitri Maximovich - "Peak performance tuning of CMP 2.0 Entity beans in WebLogic Server 8.1 and 9.0"http://dev2dev.bea.com/pub/a/2005/11/tuning-cmp-ejbs.html?page=3
This contains the worrying sentence :
In contrast to the read-mostly pattern, which doesn't provide mechanisms to notify other nodes in the cluster that data was changed on one of the nodes, when a bean with optimistic concurrency is updated, a notification is broadcast to other cluster members, and the cached bean instances are discarded to prevent optimistic conflicts.
I don't particulary want to use an optimistic concurrency in my current development as the application is guaranteed sole access to the underlying database and for the data we're concerned with there are extremely infrequent updates. My first thoughts were that a read-mostly pattern would be ideal for our requirements. However, I would be extremely concerned by the prospect of stale data existing on some nodes as I was planning on also setting read-timeout-seconds to zero.
Anyone who can shed some light on the subject would be much appreciated.
Thanks
Brendan Buckley

You are correct. The dev2dev article is not.
The caching home interface triggers an invalidation message across the cluster members. Their cache is marked dirty and the next call to the bean will force an ejbLoad.
-- Rob
WLS Blog http://dev2dev.bea.com/blog/rwoollen/

Read-mostly

Hi!
Please, could anyone explain how to implement a read mostly pattern (for bea 7.0
or 8.1). What do I have to add in which deployment descriptor>? Do I have to manipulate
only the weblogic descriptors?
(I was looking at 8.1 docs for an example but found nothing ... )
If you've got some snippets (or a sample) I would be very grateful.
Thanks for every useful reply,
Chris.

'Read-Mostly Pattern'
http://e-docs.bea.com/wls/docs70/ejb/EJB_environment.html#1133481
thanks,
Deepak
"Chris" <[email protected]> wrote:
>
Hi!
Please, could anyone explain how to implement a read mostly pattern (for
bea 7.0
or 8.1). What do I have to add in which deployment descriptor>? Do I
have to manipulate
only the weblogic descriptors?
(I was looking at 8.1 docs for an example but found nothing ... )
If you've got some snippets (or a sample) I would be very grateful.
Thanks for every useful reply,
Chris.

JMS Wrappers can't cache JNDI lookups when using secured queues

Hi All!
We are working on a jms client, inside a webapp(servlets), using Weblogic 9.2 and Weblogic 10.3.
As we want to use secured queues and keep being efficient we tryed to use Weblogic JMS Wrappers, that should work according to the docs:
Enhanced Support for Using WebLogic JMS with EJBs and Servlets
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/j2ee.html
But we are facing a problem:
When we define a JMS Wrapper and try to cache JNDI lookups for the QueueConnectionFactory and Queue, as the docs recommend for efficiency, the connection to the queue is ignoring the user/pwd.
The JMS Wrapper is using <res-auth>Application</res-auth>.
We are creating the connection using createQueueConnection(user, pwd) from QueueConnectionFactory and after several tests it seems that the user and password are ingored unless a jndi lookup is made in the same thread, as if when there are not any thread credentials present user and password are ignored for the connection...
so the question is:
That behaviour goes against Weblogic JMS Wrapper documentation, doesn't it?
Is there then any other way to access efficiently secured queues using a servlet as a client? (iit's not an option for us to use mdbs, or ejbs).
If it helps, this seems related to this still opened spring-weblogic issue: SPR-2941 --> http://jira.springframework.org/browse/SPR-2941 and SPR-4720 --> http://jira.springframework.org/browse/SPR-4720
Thanxs
And here goes our DDs and code to reproduce:
First in pretty format:
web.xml --> http://pastebin.com/f5f85e8d4
weblogic.xml --> http://pastebin.com/f2fbe10cc
Client code --> http://pastebin.com/f586d32d9
And now emmebded in the msg:
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
 <description>WebLogic Descriptor</description>
 <resource-description>
 <res-ref-name>jms/QCF</res-ref-name>
 <jndi-name>weblogic.jms.ConnectionFactory</jndi-name>
 </resource-description>
</weblogic-web-app>weblogic.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
 <display-name> QCFWrapperCredentialsTest </display-name>
 <description> QCFWrapperCredentialsTest </description>
 <servlet id="Servlet_1">
 <servlet-name>QCFWrapperCredentialsTest</servlet-name>
 <servlet-class>QCFWrapperCredentialsTest</servlet-class>
 <load-on-startup>1</load-on-startup>
 </servlet>
 <servlet-mapping id="ServletMapping_1">
 <servlet-name>QCFWrapperCredentialsTest</servlet-name>
 <url-pattern>/Test</url-pattern>
 </servlet-mapping>
 <resource-ref>
 <res-ref-name>jms/QCF</res-ref-name>
 <res-type>javax.jms.QueueConnectionFactory</res-type>
 <res-auth>Application</res-auth>
 <res-sharing-scope>Shareable</res-sharing-scope>
 </resource-ref>
</web-app>And our test client:
import java.io.*;
import java.util.Properties;
import javax.jms.*;
import javax.naming.*;
import javax.servlet.http.*;
public class QCFWrapperCredentialsTest extends HttpServlet {
 QueueConnectionFactory factory = null;
 Queue queue = null;
 String jndiName = "java:comp/env/jms/QCF";
 String queueName= "jms/ColaEntradaConsultas";
 String user = "usuarioColas";
 String pwd = "12345678";
 String userjndi = "usuarioColas";
 String pwdjndi = "12345678";
 String serverT3URL="t3://127.0.0.1:7007";
 public void init() {
 setupJNDIResources();
 private void setupJNDIResources(){
 try {
 Properties props = new Properties();
 props.put("java.naming.factory.initial",
 "weblogic.jndi.WLInitialContextFactory");
 props.put("java.naming.provider.url",serverT3URL );
 props.put("java.naming.security.principal", userjndi);// usr
 props.put("java.naming.security.credentials", pwdjndi);// pwd
 InitialContext ic = new InitialContext(props);
 factory = (QueueConnectionFactory) ic.lookup(jndiName);
 queue = (Queue) ic.lookup(queueName);
 } catch (NamingException e) {
 e.printStackTrace();
 public void service(HttpServletRequest req, HttpServletResponse res) {
 res.setContentType("text/html");
 Writer wr = null;
 try {
 wr = res.getWriter();
 //Comment this out, do a lookup for each request and it will work
 //setupJNDIResources();
 String user = this.user;
 String pwd = this.pwd;
 //read users and passwords from the request in case they are present
 if (req.getParameter("user") != null) {
 user = req.getParameter("user");
 if (req.getParameter("pwd") != null) {
 pwd = req.getParameter("pwd");
 wr.write("JNDI User: *" + userjndi + "* y pwd: *" + pwdjndi + "*");
 wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*");
 //Obtain a connection using user/pwd
 QueueConnection conn = factory.createQueueConnection(user, pwd);
 QueueSession ses = conn.createQueueSession(true,
 Session.SESSION_TRANSACTED);
 QueueSender sender = ses.createSender(queue);
 TextMessage msg = ses.createTextMessage();
 msg.setText("Hi there!");
 conn.start();
 sender.send(msg);
 ses.commit();
 sender.close();
 ses.close();
 conn.close();
 } catch (Exception e) {
 e.printStackTrace();
 try {
 wr.write(e.toString());
 } catch (Exception e2) {
 e2.printStackTrace();
 finally{
 try {
 wr.close();
 } catch (IOException e) {
 e.printStackTrace();
}Edited by: user2525402 on Feb 9, 2010 7:14 PM

Thanks Tom,
Quite a useful response .-)
Leaving aside the fact that weblogic behaviour with jms wrappers and secured queues seems to not be working as the docs says...
Talking about workarounds:
Both workarounds you suggest works, but as you already noted, creating a new JNDI context just to inject credentials into the threads is overkill when high performance is needed.
I also found more information about the same issue here: http://sleeplessinslc.blogspot.com/2009/04/weblogic-jms-standalone-multi-threaded.html
And he suggest the same workaround, injecting credentials
So I tried the second approach, successfully, injecting credentials into the thread using the security API.
This way, using JMS wrappers and injecting credentials into the thread we get the best performance available, caching resource using wrappers and using credentials in a somewhat efficient way.
Now the test snippet looks like this:
import java.io.*;
import java.security.PrivilegedAction;
import java.util.Properties;
import javax.jms.*;
import javax.naming.*;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginException;
import javax.servlet.http.*;
import weblogic.jndi.Environment;
import weblogic.security.auth.Authenticate;
public class JMSWrapperCredentialsTest extends HttpServlet {
 QueueConnectionFactory factory = null;
 Queue queue = null;
 String jndiName = "java:comp/env/jms/QCF";
 String queueName= "jms/ColaEntradaConsultas";
 String user = "usuarioColas";
 String pwd = "12345678";
 String userjndi = "usuarioColas";
 String pwdjndi = "12345678";
 String serverT3URL="t3://127.0.0.1:7007";
 public void init() {
 setupJNDIResources();
 private void setupJNDIResources(){
 try {
 Properties props = new Properties();
 props.put("java.naming.factory.initial",
 "weblogic.jndi.WLInitialContextFactory");
 props.put("java.naming.provider.url",serverT3URL );
 props.put("java.naming.security.principal", userjndi);// usr
 props.put("java.naming.security.credentials", pwdjndi);// pwd
 InitialContext ic = new InitialContext(props);
 factory = (QueueConnectionFactory) ic.lookup(jndiName);
 queue = (Queue) ic.lookup(queueName);
 } catch (NamingException e) {
 e.printStackTrace();
 public void service(HttpServletRequest req, HttpServletResponse res) {
 final HttpServletRequest fReq=req;
 final HttpServletResponse fRes=res;
 PrivilegedAction action = new java.security.PrivilegedAction() {
 public java.lang.Object run() {
 performRequest(fReq,fRes);
 return null;
 try {
 Subject subject=createSingleSubject(serverT3URL,user,pwd);
 weblogic.security.Security.runAs(subject, action);
 } catch (Exception e) {
 e.printStackTrace();
 public void performRequest(HttpServletRequest req, HttpServletResponse res) {
 res.setContentType("text/html");
 Writer wr = null;
 try {
 wr = res.getWriter();
 //Comment this out, do a lookup for each request and it will work
 //setupJNDIResources();
 String user = this.user;
 String pwd = this.pwd;
 //read users and passwords from the request in case they are present
 if (req.getParameter("user") != null) {
 user = req.getParameter("user");
 if (req.getParameter("pwd") != null) {
 pwd = req.getParameter("pwd");
 wr.write("JNDI User: *" + userjndi + "* y pwd: *" + pwdjndi + "*");
 wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*");
 //Obtain a connection using user/pwd
 QueueConnection conn = factory.createQueueConnection(user, pwd);
 QueueSession ses = conn.createQueueSession(true,
 Session.SESSION_TRANSACTED);
 QueueSender sender = ses.createSender(queue);
 TextMessage msg = ses.createTextMessage();
 msg.setText("Hi there!");
 conn.start();
 sender.send(msg);
 ses.commit();
 sender.close();
 ses.close();
 conn.close();
 } catch (Exception e) {
 e.printStackTrace();
 try {
 wr.write(e.toString());
 } catch (Exception e2) {
 e2.printStackTrace();
 finally{
 try {
 wr.close();
 } catch (IOException e) {
 e.printStackTrace();
 private Subject createSingleSubject(String providerUrl, String userName, String password) {
 Subject subject = new Subject();
 // Weblogic env class
 Environment env = new Environment();
 if(providerUrl!=null)
 env.setProviderUrl(providerUrl);
 env.setSecurityPrincipal(userName);
 env.setSecurityCredentials(password);
 try {
 // Weblogic Authenticate class will populate and Seal the subject
 Authenticate.authenticate(env, subject);
 return subject;
 catch (LoginException e) {
 throw new RuntimeException("Unable to Authenticate User", e);
 catch (Exception e) {
 throw new RuntimeException("Error authenticating user", e);
}Thanks a lot for the help

Ejb-ref, ejb-link or JNDI lookup

If I have an application in which one EJB is using another EJB in the SAME application,
what is the best of way of accessing the other EJB?
Why would I use ejb-ref / ejb-link instead of just looking it up in the JNDI?
Just curious.
Thanks.
Dan

ejb-ref/ejb-link were introduced in the ejb spec to allow bean developers to
develop beans without any knowledge of the environment into which they would
be deployed. If you can live with hard coded jndi names then that is fine or
you can use the mechanism define below but using ejb-ref/ejb-link makes your
beans more reuseable and less dependent on the final environement.
If both the ejbs are in the same application I would recommend using ejb-ref
and ejb-link.
-- Anand
"Chad McDaniel" <[email protected]> wrote in message
news:[email protected]..
"Dan Baumbach" <[email protected]> writes:
If I have an application in which one EJB is using another EJB in the
SAME application,
what is the best of way of accessing the other EJB?
Why would I use ejb-ref / ejb-link instead of just looking it up in theJNDI?
>>
>
I believe that ejb-ref/link is not useful in most systems and causes
another level of complexity to maintain. Since EJBs are complex enough
I think that using the basic JNDI lookup is preferable. Also, this
frees you to move the beans to a remote server if you ever want to.
The simplest and most flexible technique, I believe, is to use a
utility class that handles all EJB lookups for you and use a simple
EJB and JNDI name mapping that this class can generate the JNDI name
with a simply manipulation of the bean name. If you ever change the
reference technique you will then only have one class to modify.
This is also a good place to cache home references.

EJB 3.0 JNDI lookup gives ClassCastException

The object returned by the JNDI lookup of a EJB 3.0 Statefull Session Bean is not of the expected type, but rather of an obviously generated Proxy type (ejb_DistributionProcessor_LocalProxy_4h350 instead of expected DistributionProcessor). Does anybody have any idea about what this could be?
Details:
We are using annotations @Statefull and @Local and are deploying on a standalone OC4J 10.1.3.1. The beans are presumably loaded correctly since they get listed in Enterprise Managers list of beans for the application. There is also obviously an object at the desired JNDI location, presumably some kind of proxy. Unfortunately the proxy cannot be cast to the original type making the retrieved object useless.
I can supply more details if necessary, but really don't know what more is relevant.

Well, I figured it out, it seems I had the classes in both the EJB and the WEB deployment, so when casting it tried to cast X from EJB to X from WEB application and since they reside in different locations they weren't the same file and therefore not castable.

JNDI lookup fails in a thread created by J2EE application on WAS 8.0.0.4 running on Red Hat Enterprise Server 5.8(2.6.18-308.e15).

I am using Jackrabbit Repository (jcr's implementation) as backend in my Web Appl.Whose data persists on Oracle Database. To make connection with Oracle database jackrabbit provide provision of JNDI Lookup to read the data source defined in WAS (using WAS 8.0.0.4 as App Server).
I am able to perform JNDI Lookup everywhere in my application,But in a flow where i am creating a Thread using Java Concurrent Api and insidethread's call() method when I am trying for JNDI Look following exception occurs –
[8/20/13 10:57:35:163 IST] 000000dd System Out O ERROR 20-08 10:57:35,163 (DatabaseFileSystem.java:init:209) failed to initialize file system
javax.jcr.RepositoryException: JNDI name not found: java:comp/env/jdbc/ofsds
at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:295)
at org.apache.jackrabbit.core.util.db.ConnectionFactory.createDataSource(ConnectionFactory.java:233)
at org.apache.jackrabbit.core.util.db.ConnectionFactory.getDataSource(ConnectionFactory.java:166)
at org.apache.jackrabbit.core.fs.db.DbFileSystem.getDataSource(DbFileSystem.java:226)
at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190)
at org.apache.jackrabbit.core.config.RepositoryConfigurationParser$6.getFileSystem(RepositoryConfigurationParser.java:1057)
at org.apache.jackrabbit.core.config.RepositoryConfig.getFileSystem(RepositoryConfig.java:911)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:285)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:605)
at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:232)
at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:280)
at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:376)
at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:408)
at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:355)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.RepositoryStartupService_$$_javassist_1.newSession(RepositoryStartupService_$$_javassist_1.java)
at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager.create(ICMHouseKeepingSessionManager.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager_$$_javassist_8.create(ICMHouseKeepingSessionManager_$$_javassist_8.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
at org.jboss.seam.Component.newInstance(Component.java:2054)
at org.jboss.seam.Component.getInstance(Component.java:1948)
at org.jboss.seam.Component.getInstance(Component.java:1910)
at org.jboss.seam.Component.getInstance(Component.java:1904)
at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
at org.jboss.seam.Component.getValueToInject(Component.java:2223)
at org.jboss.seam.Component.injectAttributes(Component.java:1663)
at org.jboss.seam.Component.inject(Component.java:1481)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.ICMHouseKeepingRepository_$$_javassist_7.create(ICMHouseKeepingRepository_$$_javassist_7.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
at org.jboss.seam.Component.newInstance(Component.java:2054)
at org.jboss.seam.Component.getInstance(Component.java:1948)
at org.jboss.seam.Component.getInstance(Component.java:1910)
at org.jboss.seam.Component.getInstance(Component.java:1904)
at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
at org.jboss.seam.Component.getValueToInject(Component.java:2223)
at org.jboss.seam.Component.injectAttributes(Component.java:1663)
at org.jboss.seam.Component.inject(Component.java:1481)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
at com.mmpnc.icm.server.repository.ICMHouseKeepingManager_$$_javassist_6.create(ICMHouseKeepingManager_$$_javassist_6.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
at org.jboss.seam.Component.newInstance(Component.java:2054)
at org.jboss.seam.Component.getInstance(Component.java:1948)
at org.jboss.seam.Component.getInstance(Component.java:1910)
at org.jboss.seam.Component.getInstance(Component.java:1904)
at org.jboss.seam.Component.getInstance(Component.java:1899)
at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:136)
at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:149)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
at java.lang.Thread.run(Thread.java:770)
Caused by:
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:552)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:481)
at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:280)
... 114 more
Caused by:
javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1969)
at com.ibm.ws.naming.ipbase.NameSpace.retrieveBinding(NameSpace.java:1376)
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1219)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1141)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1436)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
... 119 more

Okay "damorgan", you seem to have me confused with a newbie. All I'm posting is the info that I got from my Sys Admin on the fix to my problem I encountered when trying to install Oracle 11g (11.2.0.0) on Red Hat Linux Enterprise 5. Since we're mouting onto an NFS, these are the steps he took. I'm not trying to "hide" information or post as little as possible. What other info do you want? I don't know what you are referring to when you mention "Filer, make, model, software version"? Please elaborate. I was just trying to post to others that may have encountered this problem, and I get somewhat attacked by you. I don't assume anyone can read my mind (especially you).

JAVA client JNDI lookup for EJB session in cluster in WLS 5.1

The documentation says :
 to obtain a Context for JNDI lookup do the following :
 Hashtable ht = new Hashtable();
 ht.put(Context.INITIAL_CONTEXT_FACTORY,
 "weblogic.jndi.WLInitialContextFactory");
 ht.put(Context.PROVIDER_URL, "t3://mycluster:7001");
 try {
 Context ctx = new InitialContext(ht);
 // Do the client's work
 catch (NamingException ne) {
 // A failure occurred
 finally {
 try {ctx.close();}
 catch (Exception e) {
 // a failure occurred
 where "mycluster" is the DNS name of my cluster. My DNS server (Windows 200
 DNS server) use round robin
 to call alernatively all the wls server node in "mycluster" and it's OK. The
 two servers of my cluster
 are called alternatively for my EJB session stateless.
 Now I unplug one of the two nodes of my cluster and the remaining server is
 called only 2 times
 and not after.
 Questions :
 -is the load balancing between the nodes of mycluster only rely on DNS or
 is there an internal
 mecanism in EJB sub to try one server then an other ?
 - do I need to obtain a new reference on JNDI Context for each call ?
 Thank's a lot.
 Farid Bellameche.


 I too have the same problem. My scenario is :
 I have the web tier architecture away from cluster. All ejbs are in cluster
 running in two seperate machines. We have a factory class running in
 webtier(we use servlet in this tier) which obtains home interface only once
 and stores it for future reference. When ever we need the remoteobject stub,
 we ask the factory class and which in turn uses the stored home interface to
 get the same.
 In the webtier, I list all the servers in the cluster as a part of url as
 mentioned by you.
 I started the web tier as well as Object tier cluster. I could see the
 request coming in both the machines in the cluster for the ejb. But When I
 bring one the server in the cluster,
 1. Web tier throws an exception saying that it could not connect
 to server using t3.
 2. The other machine which is running the server, also says
 'failed to create socket to : -32323234324 sever name
 using protocol t3.
 It looks like I am able to get load balance. But I am not able to get the
 fail over to be working.
 In the weblogic-ejb-jar.xml, I added the following.
 <clustering-descriptor>
 <home-is-clusterable>true</home-is-clusterable>
 <home-load-algorithm>round-robin</home-load-algorithm>
 </clustering-descriptor>
 I compiled and added the .jar file. So the jar file now has replica aware
 stubs.
 Could any one of you help me for why the fail over is not working?
 Suersh
 "Giri Alwar" <[email protected]> wrote in message
 news:[email protected]...
 > Farid,
 > (1) Yes, the stub has the logic to perform load-balancing and
 fail-over.
 > (2) In almost all cases, no. You can get the context once, store it
 and
 > use it thereafter. Please refer to
 > http://www.weblogic.com/docs51/cluster/concepts.html#1025061 for more
 info.
 >
 > A couple of notes on your situation. From what you are describing, your
 > Windows DNS server is setup to serve only one IP from the cluster (using
 > round-robin) as opposed to a list of all IP's in the cluster. Hence, the
 > initial context you obtain is tied to a single server in the cluster (the
 > one returned by the DNS). The weblogic implementation on the client side
 has
 > no idea of the existence of the other servers in the cluster. This is not
 a
 > cluster aware context. To obtain a cluster aware context, either list all
 > the IP's in the URL like t3://server1,server2,server3:7001 or have
 > "mycluster" return a list of all servers in the cluster.
 >
 > Giri
 >
 >
 > "Farid Bellameche" <[email protected]> wrote in message
 > news:[email protected]...
 > > The documentation says :
 > >
 > > to obtain a Context for JNDI lookup do the following :
 > > Hashtable ht = new Hashtable();
 > > ht.put(Context.INITIAL_CONTEXT_FACTORY,
 > > "weblogic.jndi.WLInitialContextFactory");
 > > ht.put(Context.PROVIDER_URL, "t3://mycluster:7001");
 > > try {
 > > Context ctx = new InitialContext(ht);
 > > // Do the client's work
 > > }
 > > catch (NamingException ne) {
 > > // A failure occurred
 > > }
 > > finally {
 > > try {ctx.close();}
 > > catch (Exception e) {
 > > // a failure occurred
 > > }
 > > }
 > >
 > > where "mycluster" is the DNS name of my cluster. My DNS server (Windows
 > 200
 > > DNS server) use round robin
 > > to call alernatively all the wls server node in "mycluster" and it's OK.
 > The
 > > two servers of my cluster
 > > are called alternatively for my EJB session stateless.
 > > Now I unplug one of the two nodes of my cluster and the remaining server
 > is
 > > called only 2 times
 > > and not after.
 > >
 > > Questions :
 > > -is the load balancing between the nodes of mycluster only rely on DNS
 > or
 > > is there an internal
 > > mecanism in EJB sub to try one server then an other ?
 > >
 > > - do I need to obtain a new reference on JNDI Context for each call ?
 > >
 > >
 > > Thank's a lot.
 > >
 > > Farid Bellameche.
 > >
 > >
 > >
 > >
 >
 >

JNDI Lookup for EJB3 (Bean to Bean)

Hi Forum,
i've search the whole internet and two books but I could not find an answer that pleased me.
I want to get a reference to an EJB3 by JNDI Lookup. With container managed dependency injection everything works fine but I have to do a little more generic way, thats why I want to work with JNDI Lookup.
I have the following situation:
At first I have a stateless bean
@Local
public interface Job {
     * run the job
     * @return true if the job executed without errors
    public boolean run(SchedulerConfig schedulerConfig ,JobContext context);
@Local
public interface AConcreteJobLocal extends Job {
//no more declarations
@Stateless
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class AConcreteJobBean implements AConcreteJobLocal {
//implemented methods goes here | removed for better overview in the post
} This is a typical declaration for a bunch of jobs I have. Every concrete job has it's own bean if it necessary in some way for you to know.
So now I wanted to write a bean which returns me an bean instance via a JNDI lookup
@Stateless
public class JobJNDILookupBean implements JobJNDILookupLocal {
    Logger logger = Logger.getLogger(JobJNDILookupBean.class.getName());
    public Job getJobBeanFromJNDIName(String jndiName) {
        Job job = null;
        try {
            Context c = new InitialContext();
            job = (Job) c.lookup("jndiName");
        } catch (NamingException ex) {
            Logger.getLogger(JobJNDILookupBean.class.getName()).log(Level.SEVERE, null, ex);
        } catch (IllegalArgumentException ex) {
            logger.log(Level.SEVERE, "Bean not found", ex);
        return job;
}When I call this method I always get a NameNotFoundException
javax.naming.NameNotFoundException: JNDI_NAME_GOES_HERE not found
        at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
        at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
        at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
        at com.sun.enterprise.naming.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:111)
        at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
        at javax.naming.InitialContext.lookup(InitialContext.java:351)
        at com.vw.ais.dcl.timer.engine.JobJNDILookup.getJobBeanFromJNDIName(JobJNDILookup.java:46)
        at com.vw.ais.dcl.timer.engine.EngineBean.init(EngineBean.java:221)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
        at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83)
        at $Proxy713.init(Unknown Source)
        at com.vw.ais.dcl.timer.SchedulerBean.runEngine(SchedulerBean.java:192)
        at com.vw.ais.dcl.timer.SchedulerBean.handleIncomingByTimer(SchedulerBean.java:171)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
        at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
        at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2824)
        at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1401)
        at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:99)
        at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1952)
        at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.service(EJBTimerService.java:1948)
        at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)I've tried I guess all combinations for the JNDI_NAME
java:/comp/env/ejb/AConcreteJob
java:/comp/env/ejb/AConcreteJobLocal
java:/comp/env/ejb/AConcreteJobBean
java:/comp/env/AConcreteJob
java:/comp/env/full.package.and.Class.name
this all without java:/comp/env
etc.
The only way it worked was when I added a annotation to the JobJNDILookupBean in this way
@Stateless
*@EJB(name="ejb/AConcreteJob",beanInterface=A.Interface.location)*
public class JobJNDILookupBean implements JobJNDILookupLocal {
}But this is not what I want to do. Thats why my question. How can I lookup a bean without annotate it in the bean which want to look it up???
In other words whats wrong here
@Stateless
public class JobJNDILookupBean implements JobJNDILookupLocal {
    Logger logger = Logger.getLogger(JobJNDILookupBean.class.getName());
    public Job getJobBeanFromJNDIName(String someJndiName) {
        Job job = null;
        try {
            Context c = new InitialContext();
            job = (Job) c.lookup("someJndiName");
        } catch (NamingException ex) {
            Logger.getLogger(JobJNDILookupBean.class.getName()).log(Level.SEVERE, null, ex);
        } catch (IllegalArgumentException ex) {
            logger.log(Level.SEVERE, "Bean not found", ex);
        return job;
}I hope you understand my question and more than this I hope some has the answer.

Hi Zsom,
Zsom wrote:
One thing you need to keep in mind is that beans aren't instantiated every time you make a call to your EJB. You're right! But because the fact the beans are all stateless it doesn't matter. I don't want to get a new EJB at a lookup. If I get a reference to a bean which was used a million times before it is absolutely ok
Zsom wrote:
You might be gaining some time because the container can create new beans more quickly, but you are also looking up the beans before each call, which in the long run will be even more expensive.Mhm, I don't know if I understand you. Maybe I explain my process a little bit. I have a lot of different jobs in my application (JobDoThis, JobDoThat, JobFoo, JobBar). Every job has a own bean which keeps the business logic. Furthermore I have an job engine which is able to execute jobs which are configured to run and this engine can solve some dependencies (If JobFoo fails don't execute JobBar , and so on). When I build my engine I want to get a reference to a jobBean by jndi lookup which keeps the business logic and then call some method on it. This means that the lookup will only be called when I build a new engine. And because this doesn't happen so often performance is not so important. Furthermore if all jobs all configured to run the application needs sometimes more than 12 hours (depended from the amount of data) for one run (Start to End -> the application has a little script character), that's why performance as I said already is not so important.
Zsom wrote:
But it would be worth making some test, because to me it seems a bit like bad design.Yes it could be, but this was my first thought to instantiate a bean (or get a reference to an existing one) dynamically. I don't like this hard coded dependency injection. I mean it's great If you know at compiletime which beans you need. But because we don't know which beans we need it's a big overhead to inject them all by container and then use only 40 percent of the injected bean because for example only 40 of 100 jobs shall run.
If there is another approach to get a reference dynamically which is better than this then I will try, no problem, but unfortunally I don't see another.

JNDI lookup for UserTransaction

 Hi all,
 in Weblogic, in a typical scenario, do a client provide exactly
 one JNDI lookup for the UserTransaction object (interface) or do
 the client have to provide a JNDI lookup for each transaction?
 In some EJB implementations, a JNDI lookup for UserTransaction
 returns always the same reference. For example, in JOnAS, you can
 have one static reference which is set when the client starts.
 Then, more threads can simultaneously use the same static
 UserTransaction reference without any conflict, since the
 implementation of UserTransaction recognizes, which thread invoked
 a particular method.
 In other words, can I make an assumption that two different JNDI
 lookups for UserTransaction returns different references or not?
 Thanks a lot,
 Marek Prochazka
 Distributed Systems Research Group
 Department of Software Engineering
 Charles University, Faculty of Mathematics and Physics
 Malostranske namesti 25, 118 00 Prague 1, Czech Republic
 phone: +420-2-2191 4236
 http://nenya.ms.mff.cuni.cz/thegroup/


Actually, UserTransaction is a singleton and it's not a transaction. It's just
 very mis-named.
 It should be called UserTransactionManager or UserInterfaceToJTA.
 The actual transaction is javax.transaction.Transaction.
 -- Rob
 Cameron Purdy wrote:
 > Within a transaction, it is different instances? For example, if you call
 > it two times one right after another?
 >
 > A transaction is a unit of work. I understand why the transaction object
 > changes from transaction to transaction, since a single transaction object
 > (UserTransaction) represents exactly one transaction. Why would it be a
 > singleton? It is not a transaction manager.
 >
 > Peace,
 >
 > --
 > Cameron Purdy
 > Tangosol, Inc.
 > http://www.tangosol.com
 > +1.617.623.5782
 > WebLogic Consulting Available
 >
 > "Sarita" <[email protected]> wrote in message
 > news:[email protected]...
 > >
 > > Hi Priscilla--
 > >
 > > This is not the behavior that I'm seeing, and I'm perplexed.
 > > Every time I request a UserTransaction from JNDI, I receive a
 > > a different instance. Should the value immediately returned by JNDI be
 > the singleton
 > > instance? If not, then how do I retrieve the singleton instance?
 > >
 > > I would like a session bean to start a transaction, and then call a method
 > on another
 > > session bean (which should operate under the same transaction). How does
 > the second
 > > session bean grab the correct transaction object? Is that possible?
 > >
 > > Thanks In Advance,
 > > Sarita
 > >
 > > "Priscilla Fung" <[email protected]> wrote:
 > > >
 > > >Hi Marek,
 > > >
 > > >In Weblogic 6.0, JNDI lookup of UserTransaction returns a reference to
 > the
 > > >singleton
 > > >Transaction Manager instance, which is thread-safe and can be used from
 > > >multiple
 > > >threads for transaction demarcations etc.
 > > >
 > > >-- Priscilla Fung, BEA Systems, Inc.
 > > >
 > > >"Marek Prochazka" <[email protected]> wrote:
 > > >>
 > > >>Hi all,
 > > >>
 > > >>in Weblogic, in a typical scenario, do a client provide exactly
 > > >>one JNDI lookup for the UserTransaction object (interface) or do
 > > >>the client have to provide a JNDI lookup for each transaction?
 > > >>
 > > >>In some EJB implementations, a JNDI lookup for UserTransaction
 > > >>returns always the same reference. For example, in JOnAS, you can
 > > >>have one static reference which is set when the client starts.
 > > >>Then, more threads can simultaneously use the same static
 > > >>UserTransaction reference without any conflict, since the
 > > >>implementation of UserTransaction recognizes, which thread invoked
 > > >>a particular method.
 > > >>
 > > >>In other words, can I make an assumption that two different JNDI
 > > >>lookups for UserTransaction returns different references or not?
 > > >>
 > > >>Thanks a lot,
 > > >>Marek Prochazka
 > > >>--------------------------------------------------------------
 > > >> Distributed Systems Research Group
 > > >> Department of Software Engineering
 > > >> Charles University, Faculty of Mathematics and Physics
 > > >> Malostranske namesti 25, 118 00 Prague 1, Czech Republic
 > > >> phone: +420-2-2191 4236
 > > >> http://nenya.ms.mff.cuni.cz/thegroup/
 > > >>--------------------------------------------------------------
 > > >>
 > > >
 > >

Minimizing JNDI lookups

Hi!
We've implemented a simple EJBHome caching mechanism to reduce JNDI lookups. As many of you may know, a JNDI lookup is expensive in resource terms.
Using the Oracle 9iAS JavaCache service is discarded because we need a vendor independant solution.
Our implementation works fine in an OC4J standalone environment where each EJB is looked up and created in the same instance.
But we don't know how it would perform in a clustered environment (Oracle 9iAS Enterprise) and we don't have an installation avalaible to try it and make the performance improvement announcement for our customers. (they are asking us to do it ASAP).
So the key here is when the EJB load balance happens?, in the JNDI lookup or in the EJB create() method ?
Thanks
Franco Catrin L.
TUXPAN

I'm using a Singleton class to cache HomeInterfaces. The first time a
HomeInterface is requested, the JNDI lookup is done, after that, all
requests to that HomeInterface are handled by the cache. Works great, no
problems. AFAIK there are no problems with storing the HomeInterface
reference and reusing it.
Hope that helps,
Nils
Tiffany wrote:
>
JNDI lookups are expensive timewise. Our question is ... would it be
pratical to lookup all our EJB Home interfaces once at startup and store
these references in a global class accessible to all clients? These home
interfaces then become readily available factories for acquiring instances
of remote interfaces. Is there anything wrong with this picture? Is this a
problem because these home stubs are not reentrant and may be accessed
concurrently by more than one client? Is there a problem with have one home
reference create multiple remote references of an ejb?
Any light that can be shed on this question wouls be appreciated.
Thanks.
tiffany
San Diego--
============================
[email protected]

JNDI lookup fails - No such domain/application

Hi,
I tried to perform a JNDI lookup from a stand alone Java client towards Oracle 9iAS version 9.0.3 and failed with the following error:
javax.naming.NamingException: Lookup error: javax.naming.AuthenticationException: No such domain/application: mindejb; nested exception is:
 javax.naming.AuthenticationException: No such domain/application: mindejb
 java.lang.Object com.evermind.server.rmi.RMIContext.lookup(java.lang.String)
 RMIContext.java:134
 java.lang.Object javax.naming.InitialContext.lookup(java.lang.String)
 InitialContext.java:345
 void Samplecom.mind.ejb.stubs.AccountComplexStubClient.main(java.lang.String[])
 AccountComplexStubClient.java:21
Below, are the JNDI settings I am using. The application by the name mindejb was deployed and is accessible using server side JSP or servlets. When I use a stand alone OC4J, the same settings (different port) work fine!
java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory
java.naming.provider.url=ormi://localhost:3101/mindejb
java.naming.security.principal=admin
java.naming.security.credentials=admin
Thanks,
Avi

When you are running within an Oracle Application Server managed OC4J environment, then you should use the OPMN protocol loader we have that will insulate you from the specified ORMI port being used by OC4J.
The OPMN port is fixed so you can always rely on it, whereas the specific ORMI port used by an OC4J instance changes depending on the startup sequence, the number of procs configured, etc.
Here's a piece from the EJB documentation
http://download-west.oracle.com/docs/cd/B14099_19/web.1012/b15505/access.htm#i1019709
Location
All ports, including the RMI port, are dynamically set by OPMN when each OC4J instance starts. When you specify the following URL in the client JNDI properties, the client-side OC4J retrieves the dynamic ports for the instance, and chooses one from the list for communication.
java.naming.provider.url= opmn:ormi://<opmn_host>:<opmn_port>:<oc4j_instance>/<application-name>
The OPMN host name and port number is retrieved from the opmn.xml file. In most cases, OPMN is located on the same machine as the OC4J instance. However, you must specify the host name in case it is located on another machine. The OPMN port number is optional; if excluded, the default is port 6003. The OPMN port is specified in opmn.xml.
cheers
-steve-

JNDI lookup for weblogic.management.MBeanHome

Tried to do JNDI lookup for MBeanHome. It could resolve
weblogic.management, but not MBeanHome.
Any idea? Thank you
T. Pei
PS
The statement and the error message:
MBeanHome mBeanHome = (MBeanHome) initialContext.lookup
("weblogic.management.MBeanHome.JNDI_NAME.MyServer");
javax.naming.NameNotFoundException:
Unable to resolve weblogic.management.MBeanHome.JNDI_NAME.MyServer
Resolved: 'weblogic.management'
Unresolved:'MBeanHome' ; remaining name 'JNDI_NAME.MyServer'

I answered this in my last post, but to clarify your attempt below.
you can access MBeanHome through JNDI in any of three ways that I
currently know...
MBeanHome mBeanHome =
(MBeanHome)ctx.lookup("weblogic.management.adminhome");
MBeanHome mBeanHome =
(MBeanHome)ctx.lookup(MBeanHome.ADMIN_JNDI_NAME);
MBeanHome mBeanHome =
(MBeanHome)ctx.lookup(MBeanHome.JNDI_NAME+"."+yourservername);
typically yourservername = "myserver"
when I print MBeanHome.ADMIN_JNDI_NAME I get
"weblogic.management.adminhome"
when I print MBeanHome.JNDI_NAME I get
"weblogic.management.home"
so using MBeanHome.JNDI_NAME+"."+yourservername is the same as
"weblogic.management.home.myserver", if the server you are trying to access
is called myserver.
may be more information than you want.
"T. Pei" <[email protected]> wrote in message
news:3a7a1562$[email protected]..
>
Tried to do JNDI lookup for MBeanHome. It could resolve
weblogic.management, but not MBeanHome.
Any idea? Thank you
T. Pei
PS
The statement and the error message:
MBeanHome mBeanHome = (MBeanHome) initialContext.lookup
("weblogic.management.MBeanHome.JNDI_NAME.MyServer");
javax.naming.NameNotFoundException:
Unable to resolve weblogic.management.MBeanHome.JNDI_NAME.MyServer
Resolved: 'weblogic.management'
Unresolved:'MBeanHome' ; remaining name 'JNDI_NAME.MyServer'

More read-mostly pattern & JNDI Lookup.

Similar Messages

Maybe you are looking for