InitialContext caching previous lookups?

Weblogic 6.1 SP3
Currently, all of our beans lookup the homes of other beans they need in the ejbCreate
method. Our session beans lookup entity beans in their ejbCreate methods. Some
of these session beans use the same entity beans and I think it is inefficient
to have different session beans lookup the same entity beans multiple times.
I designed a simple Service Locator singleton in my server. Basically, in the
Session Bean's ejbCreate, the home is taken from the Service Locator's cache.
If the Service Locator doesn't have the home in cache, it creates it. Therefore,
if I have 10 session beans looking up the same entity bean, the bean will only
be looked up once instead of 10 times.
I did some timing tests and found that the optimization really didn't improve
the performance at all.
Therefore, I'm wondering if Weblogic is doing any caching of previously looked
up homes in their implementation of the InitialContext. Does anyone know if Weblogic
is doing this?
Thanks.
Dan

Why not DataSources ?
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
>
I am caching the results (except the DataSources...), but I'd like toreuse the
InitialContext across calls so I dont need to call new InitialContext()for each
lookup.
Any advise?
"Dimitri I. Rakitine" <[email protected]> wrote:
Since the lookups are expensive (in 6.x and 7.0), I think that you'll
be
better off caching lookup results.
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
I seem to be unable to find a best practice for caching InitialContextobjects.
I'm doing some profile on my current project to pinpoint hotspots foroptimizations
and the creation of IC seems to be one of those areas.
Is it recommended to use a singleton approach to InitialContext?
How about an object pool?
Or an instance per object for internal reuse?
Will an IC object ever be invalidated (will I need to recreate theobject
under
certain circumstances?)
Any feedback is appreciated.
Thanks,
Doug--
Dimitri
Dimitri

Similar Messages

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 + "*<p>");
            wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*<p>");
            //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 + "*<p>");
            wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*<p>");
            //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

InitialContext Caching

I seem to be unable to find a best practice for caching InitialContext objects.
I'm doing some profile on my current project to pinpoint hotspots for optimizations
and the creation of IC seems to be one of those areas.
Is it recommended to use a singleton approach to InitialContext?
How about an object pool?
Or an instance per object for internal reuse?
Will an IC object ever be invalidated (will I need to recreate the object under
certain circumstances?)
Any feedback is appreciated.
Thanks,
Doug

Why not DataSources ?
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
>
I am caching the results (except the DataSources...), but I'd like toreuse the
InitialContext across calls so I dont need to call new InitialContext()for each
lookup.
Any advise?
"Dimitri I. Rakitine" <[email protected]> wrote:
Since the lookups are expensive (in 6.x and 7.0), I think that you'll
be
better off caching lookup results.
"Doug Larson" <[email protected]> wrote in message
news:[email protected]..
I seem to be unable to find a best practice for caching InitialContextobjects.
I'm doing some profile on my current project to pinpoint hotspots foroptimizations
and the creation of IC seems to be one of those areas.
Is it recommended to use a singleton approach to InitialContext?
How about an object pool?
Or an instance per object for internal reuse?
Will an IC object ever be invalidated (will I need to recreate theobject
under
certain circumstances?)
Any feedback is appreciated.
Thanks,
Doug--
Dimitri
Dimitri

Acrobat Pro X showing cached/previous version PDFs

Hi all,
I'm running Acrobat Pro X on Lion, and have a problem where if I make a PDF (for example in Illustrator) and open it in Acrobat, and then at a later point amend the Illustrator artwork, make a new PDF with the same file name and open it again in Acrobat I don't see the updated PDF, just the original one. If I quit and reopen Acrobat everything is fine, but I've no idea why Acrobat is showing a cached/previous version of the PDF. Any suggestions as to how I can fix this without having to quit and reopen Acrobat every time I amend a PDF?
Thanks,
Stephen

See this post.

How to cache JNDI Lookup

I want to cache JNDI Look ups for Datasources/EJBs.
I am wondering if anyone would have a suggestion for me regarding speeding
up the time it takes to execute the following code snipplets:
Context context = new InitialContext();
Object objectReference = context.lookup("someEJB");
It appears that the context.lookup is always quite a bit of time, even when
the client is running local to the EJB server.
Is there any way to serialize or "save" this lookup information so that
client apps that are looking for "someEJB" can use the saved information?
Thanks to all who will respond
Regards,
Raju ([email protected])

Please do not cross-post.
"Anjaneya Raju" <[email protected]> wrote in message
news:39994516$[email protected]..
>
>
I want to cache JNDI Look ups for Datasources/EJBs.
I am wondering if anyone would have a suggestion for me regarding speeding
up the time it takes to execute the following code snipplets:
Context context = new InitialContext();
Object objectReference = context.lookup("someEJB");
It appears that the context.lookup is always quite a bit of time, evenwhen
the client is running local to the EJB server.
Is there any way to serialize or "save" this lookup information so that
client apps that are looking for "someEJB" can use the saved information?
Thanks to all who will respond
Regards,
Raju ([email protected])

How to create InitialContext for JNDI lookup in a cluster?

          I am new to clusters in WL7 and I wanted to know how a client would create an InitialContext
          object to perform a JNDI lookup for a remote object deployed across serveral servers
          in the cluster. Is the following correct?
          Physcial Servers in the cluster
          machine1:9001
          machine2:9001
          machine3:9001
          Code for creating InitialContext
          Properties p = new Properties();
          p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
          p.put(Context.PROVIDER_URL, "machine1:9001,machine2:9001,machine3:9001");
          Context c = new InitialContext( p);
          Thanks,
          Raffi


Hi Ivaylo,
There's another alternative solution to your problem. You can have the screen 120 as a user-defined selection screen. i.e., instead of creating this screen through the screen painter, you can create it from within your ABAP Program. This way, you can directly use the SELECT-OPTIONS statement within your screen. You then will no longer have to bother about how to handle the data for the field.
Especially in the case where your screen 120 has few elements, this approach, in my opinion, will be the best.
Please let me know if you need any further clarifications on how to go about it if you choose to follow this approach.
Regards,
Anand Mandalika.

InitialContext caching to improve performance

Hi All
I was going tthrough the EJB best practices doc in http://www-106.ibm.com/developerworks/java/library/j-ejb0924.html
by Brett. He suggests caching the InitalContext object instances to boost performance.
However if I fo to the javadoc for Context - they clearly say that this :
"A Context instance is not guaranteed to be synchronized against concurrent access
by multiple threads. Threads that need to access a single Context instance concurrently
should synchronize amongst themselves and provide the necessary locking."
I am confused as to how caching will work if this is true!. OR is it that if the
only use of Context is to lookup objects and not to bind objects - then only I
can use caching? My application uses the Context objects to lookup other objects
(EJB/JMS) on the JNDI tree and not to bind objects - can I use the caching?
thanks
Anamitra

Correction - somehow I shifted from caching results of lookups
to transaction propagation. Surely, you can cache results of
UserTransaction lookups.
Slava
"Slava Imeshev" <[email protected]> wrote in message
news:[email protected]...
Hi Rob,
"Rob Woollen" <[email protected]> wrote in message
news:[email protected]...
No, you can cache UserTransaction. The problem is mostly in the naming.
UserTransaction should probably be called UserTransactionManager or
something like that. It represents the user's interface to the
transaction manager but not the actual transaction.It could be right for remote client TXs, I agree. Looks like I spend too
much
time on the server side recently :) Obviously, if the user tx is handledby
client
it can be "cached".
Though, it's not clear how much could be gained from "caching"
TXs in multi-threading environment considering all the expenses
and complexities connected with it.
In fact, all J2EE is about easing life of a developer by letting one
not to care about this multi-threading stuff. So I do join to Dimitri :)
Slava
I agree with Dimitri's advice in another response. Think pretty hard
about why you're using bean-managed transactions. There's very few good
reasons to do so.
-- Rob
Slava Imeshev wrote:
Hi Anamitra,
User transactions for stateless session beans must
start and end within one method. For message driven
beans user TXs must start and end within onMessage
method. Stateful session beans can begin user TX in
one client method call and finish it in another.
Effectively it means that you can't cache UserTransaction
in multiple threads.
Regards,
Slava Imeshev
"Anamitra" <[email protected]> wrote in message
news:[email protected]...
Can I cache the handle to the UserTransaction also? like I do this
once:
UserTransaction utx =(UserTransaction)cntx.lookup("javax.transaction.UserTransaction");
then use this "utx" handle to do start and end transactions in
multiple
>>>
threads?
Anamitra
"Dimitri I. Rakitine" <[email protected]> wrote:
Yes. Even better idea will be to cache results of JNDI lookups -
homes
etc.
Anamitra <[email protected]> wrote:
Hi All
I was going tthrough the EJB best practices doc in
http://www-106.ibm.com/developerworks/java/library/j-ejb0924.html
by Brett. He suggests caching the InitalContext object instances toboost performance.
However if I fo to the javadoc for Context - they clearly say thatthis :
"A Context instance is not guaranteed to be synchronized against
concurrent
access
by multiple threads. Threads that need to access a single Context
instance
concurrently
should synchronize amongst themselves and provide the necessary
locking."
I am confused as to how caching will work if this is true!. OR is itthat if the
only use of Context is to lookup objects and not to bind objects -then only I
can use caching? My application uses the Context objects to lookupother objects
(EJB/JMS) on the JNDI tree and not to bind objects - can I use thecaching?
thanks
Anamitra--
Dimitri

Iphone 4 caching previous email image? Organize by Thread bug?

Hi all,
I have a user who noticed an image that he had opened in his email previously... appear in a new email that was sent out by someone else. The new email definitely contained a new image. I confirmed this by actually taking a look at the email in his Outlook versus what was shown on his iphone.
The email happened to be within a thread (since it was the first email, I assume that it was cached even before the email was in a thread).
So I turned off organize by thread and the image then appeared to be the correct one.
Turning it back on... the image is still the correct image.
Has anyone else seen this problem?

No one has seen this?

Safari not caching previous page properly

After the last update I have had problems with going back to the previous page and it not being the last page I went to. As an example if I go the espn soccernet it will load the most recent page. If I click an article, read it and back click to the last page, it will load up a previous screen from another time I visited(ie one from another day). If I command-R, it will load the page properly. I have this problem with another service I use called chelsea sundayleague. If I set up tactics on a screen, and back click to the previous screen, it will load another dated screen. I have 2 "teams" and log in seperately for both, and sometimes back clicking loads a seperate team's page even though I have logged out.....It does this behaviour under private browsing and regular. I do use Safari Stand, if that matters... Any ideas as to what the heck is going on?? I am running safari 2.02 and Tiger 10.4.3. It does it on my imac G5 and my ibook g4...Wacky...

Private browsing seems to be causing the problem...

Informatica TT_11185 : No more lookup cache to build by additional concurrent pipeline in the current concurrent source set.

Dear friends,
One of my customer is facing the following issue with execution of three workflows which share the same mapplets (log file below):
My challenge is to understand the issue. I found many posts where the solution to this problem is to go to Session properties --> config object tab --> Additional Concurrent Pipelines for Lookup Cache Creation instead of auto set this to 0 or any numerical value.
But when I look at the log the cache files PMLKUP21053_327682_0_864013W32.[dat/idx] to support mplt_VZA_DIM_ASSET_WID_LKP.LKPTRANS mapplet was successfully created. This means we are not experiencing lack of free space issue.
There are about 15 tasks which we execute simultaneously which all share mplt_VZA_DIM_ASSET_WID_LKP and mplt_VZA_DIM_ORGANIZATION_WID_LKP mapplets. And it is only recenty three tasks started to fail. However if we restart the execution plan all complete successfully.
Could it be that we are facing Informatica setup limits on how many mapplets could be simultaneously executed? Any suggestions are welcome. This is the production issue.
Thank you!
2013-10-24 20:48:11 : INFO : (9068 | DIRECTOR) : (IS | Integration_Service) : node01_obieesvr11 : TT_11183 : Enabled using [1 (auto)] additional concurrent pipelines to build lookup caches. (Session likely will build or refresh [2] lookup caches; [0] on-demand only).
2013-10-24 20:48:11 : INFO : (9068 | MAPPING) : (IS | Integration_Service) : node01_obieesvr11 : TM_6660 : Total Buffer Pool size is 22013248 bytes and Block size is 1220736 bytes.
2013-10-24 20:48:11 : INFO : (9068 | LKPDP_1) : (IS | Integration_Service) : node01_obieesvr11 : DBG_21312 : Lookup Transformation [mplt_VZA_DIM_ORGANIZATION_WID_LKP.LKPTRANS]: Lookup override sql to create cache: SELECT INTEGRATION_ID AS INTEGRATION_ID, SOURCE_SYSTEM_ID AS SOURCE_SYSTEM_ID, SOURCE_INSTANCE_ID AS SOURCE_INSTANCE_ID, ORGANIZATION_ID AS ORGANIZATION_ID FROM T_VZA_DIM_ORGANIZATION ORDER BY SOURCE_SYSTEM_ID,SOURCE_INSTANCE_ID,ORGANIZATION_ID,INTEGRATION_ID
2013-10-24 20:48:11 : INFO : (9068 | LKPDP_2) : (IS | Integration_Service) : node01_obieesvr11 : DBG_21312 : Lookup Transformation [mplt_VZA_DIM_ASSET_WID_LKP.LKPTRANS]: Lookup override sql to create cache: SELECT INTEGRATION_ID AS INTEGRATION_ID, SOURCE_SYSTEM_ID AS SOURCE_SYSTEM_ID, SOURCE_INSTANCE_ID AS SOURCE_INSTANCE_ID, ASSET_ID AS ASSET_ID FROM T_VZA_DIM_ASSET ORDER BY SOURCE_SYSTEM_ID,SOURCE_INSTANCE_ID,ASSET_ID,INTEGRATION_ID
2013-10-24 20:48:11 : INFO : (9068 | DIRECTOR) : (IS | Integration_Service) : node01_obieesvr11 : TT_11184 : Starting additional concurrent pipeline to build the lookup cache needed by Lookup transformation [mplt_VZA_DIM_ORGANIZATION_WID_LKP.LKPTRANS].
2013-10-24 20:48:11 : INFO : (9068 | LKPDP_1) : (IS | Integration_Service) : node01_obieesvr11 : TM_6660 : Total Buffer Pool size is 609824 bytes and Block size is 65536 bytes.
2013-10-24 20:48:11 : INFO : (9068 | LKPDP_1:TRANSF_1_1) : (IS | Integration_Service) : node01_obieesvr11 : CMN_1671 : Created new cache files PMLKUP21053_393219_0_864013W32.[dat/idx] in directory C:\Infa861\server\infa_shared\Cache for Lookup [mplt_VZA_DIM_ORGANIZATION_WID_LKP.LKPTRANS].
2013-10-24 20:48:11 : INFO : (9068 | LKPDP_1:TRANSF_1_1) : (IS | Integration_Service) : node01_obieesvr11 : DBG_21641 : mplt_VZA_DIM_ORGANIZATION_WID_LKP.LKPTRANS: Index cache size = [89616384], Data cache size = [178962432]
2013-10-24 20:48:11 : INFO : (9068 | DIRECTOR) : (IS | Integration_Service) : node01_obieesvr11 : TT_11184 : Starting additional concurrent pipeline to build the lookup cache needed by Lookup transformation [mplt_VZA_DIM_ASSET_WID_LKP.LKPTRANS].
2013-10-24 20:48:17 : INFO : (9068 | LKPDP_2:TRANSF_1_1) : (IS | Integration_Service) : node01_obieesvr11 : DBG_21294 : DBG_21294 Lookup cache creation completed : (Thu Oct 24 20:48:17 2013)
2013-10-24 20:48:17 : INFO : (9068 | LKPDP_2:TRANSF_1_1) : (IS | Integration_Service) : node01_obieesvr11 : CMN_1671 : Created new cache files PMLKUP21053_327682_0_864013W32.[dat/idx] in directory C:\Infa861\server\infa_shared\Cache for Lookup [mplt_VZA_DIM_ASSET_WID_LKP.LKPTRANS].
2013-10-24 20:48:17 : INFO : (9068 | LKPDP_2:TRANSF_1_1) : (IS | Integration_Service) : node01_obieesvr11 : DBG_21641 : mplt_VZA_DIM_ASSET_WID_LKP.LKPTRANS: Index cache size = [89616384], Data cache size = [178962432]
2013-10-24 20:48:17 : INFO : (9068 | DIRECTOR) : (IS | Integration_Service) : node01_obieesvr11 : TT_11185 : No more lookup cache to build by additional concurrent pipeline in the current concurrent source set.

Congrats to Nonki and ME!!!! =^)
Small Basic Technical Guru - February 2015
Nonki Takahashi
Small Basic: Key Input
Michiel Van Hoorn: "Great improvement."
RZ: "Very nice explanation and examples of key input handling"
Ed Price - MSFT
Small Basic: The History of the Logo Turtle
RZ: "Turtle (Logo) was the first programming language for many, including perhaps some of the Small Basic prorammers. Nice article explaining the history."
Michiel Van Hoorn: "A nice background article and hopefull inspiration for those who want to start in robotics"
Nonki Takahashi
Small Basic: TechNet Wiki Article List
Michiel Van Hoorn: "This is great! Perfect as a local cache of the articles. "
RZ: "A good example"
Also worth a mention were the other entries this month:
Small Basic Known Issue: 29976 - Assignment to Array in Event Handler Needs Time by
Nonki Takahashi
RZ: "This is a very good catch. The workaround mentioned is very helpful."
Michiel Van Hoorn: "Ah, very helpfull if you ever bumped into this"
Welcome to Small Basic by
Nonki Takahashi
Michiel Van Hoorn: "Nice greating"
RZ: "A good introduction page"
Ed Price, Azure & Power BI Customer Program Manager (Blog,
Small Basic,
Wiki Ninjas,
Wiki)
Answer an interesting question?
Create a wiki article about it!

Caching initial contexts

I have read the posts about caching initial context lookups and have
implemented the solution and seen some benefits.
I am dealing with a third party application that I cannot change.
When I put my InitialContextFactory in the architecture I also logged
how many getInitialContext() calls were being made - I was absolutely
shocked - often 4+ per user transaction. I suspect that the code gets
one, does a call and dereferences all over the place.
90% of InitialContexts had the same environment passed to the getIC()
call so it struck me that what I should do is create a pool of IC, and
in my factory just serve one from the pool.
So, the question is, what is the best way of detecting when the IC has
been dereferenced so I know I can serve it again from my pool?
I presume this is a generic pool problem when you can't guarantee that
your client's will be good citizens and call a close() method or
similar.
I've posted here as it is performance related; also, is there any
reason why what I am doing is not a good idea?
Can the client do something with the IC which means it is not suitable
for use by another client? If so, can I detect this so I may discard?
As always, many thanks in advance.
Presuming I can get it to work I will post the code so that we can all
share ;-)
Cheers
Ed

Why don't you instrument your factory then to give out your own
implementation of InitialContext that will in fact only wrap a "loaner"
InitialContext every time a method is invoked on it and before returning
the value to the caller will put the real InitialContext back to the
pool to be reused by another one.
Then your clients can do whatever they want with those ICs and still
would not cause so big performance hits.
It's just an idea that just came to mind and I haven't tested it so it
might have flaws but it looks viable.
--dejan
Ed Barrett wrote:
The application is a third-party product that cannot be changed.
By introducing the factory you gave below (thanks!) we put the application
back under the load test and saw minimal improvements (like 1% response
time).
I then instrumented the factory with a system.out on finalize and noticed
that a factory instance is created for each call to getInitialContext() - is
this the way that WLS/J2EE works? I would have hoped that factories were
shared or something. What we did see is that for one user request a number
(sometimes 5!) ICs were being created ;-( Obviously the lookup cache is a
class instance and shared across the lot.
So then I started to think about pre-creating ICs and haveing a pool for the
default ones (environment specifies URL and no security details or the
like). Trouble is how to implement such when you cannot change the client
code to call a factory return method (such as returnToPool()).
Any ideas would be appreciated
"Dimitri I. Rakitine" <[email protected]> wrote in message
news:[email protected]...
I've ran into this problem while porting 5.1 application (JNDI lookups
were
super-cheap) to 6.1 (where they are not so cheap due to
serialization/deserialization)
and did this test to see if this indeed was the problem. As you saw I
didn't bother to
cache InitialContext's - I just cached JNDI lookups and that resulted in
very significant
performance improvements.
Which application are you testing it with?
Graham <[email protected]> wrote:
Dimitri,
We did this but did not see that much improvement over the default way -
we
are using 6.1 sp2.
We put some messages in our factory and found that the client code often
created over 4 ICs for one user click - aaggghhhh!! As I say we cannot
change their code but if we could take the time to create an IC away
from
the online response we feel we would save some time.
We also observed a new instance of the IC factory being created every
time a
new IC was created - is this what you would expect?
I think this is what NamingManager.getInitialContext() is supposed to do.
Cheers
Ed
"Dimitri I. Rakitine" <[email protected]> wrote in message
news:[email protected]...
Caching InitialContext's will probably not quite solve the problem,
because lookup()'s are expensive (in 6.x), so, caching lookup results
will result in performance improvements.
If you cannot change the 3'rd party code and all it does is:
... DataSource ds = (DataSource)new InitialContext().lookup(".....");
or similar, you can add caching by implementing your own InitialContext
factory,
for example: (extremely simplistic)
Startup class :
System.setProperty("java.naming.factory.initial",
"myjndi.InitialContextFactory");
where
myjndi.InitialContextFactory is :
public class InitialContextFactory implements
javax.naming.spi.InitialContextFactory {
public Context getInitialContext(Hashtable env) throws
NamingException
Context ctx = new
weblogic.jndi.WLInitialContextFactory().getInitialContext(env);
return
(Context)Proxy.newProxyInstance(ctx.getClass().getClassLoader(),
new Class[]
{ Context.class },
new
ContextHandler(ctx));
and myjndi.ContextHandler is:
public class ContextHandler implements InvocationHandler {
Context ctx;
static Hashtable cache = new Hashtable();
public ContextHandler(Context ctx) {
this.ctx = ctx;
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
try {
Object retVal;
if("lookup".equals(method.getName()) && args[0] instanceof
String) {
retVal = cache.get(args[0]);
if(retVal == null) {
retVal = method.invoke(ctx, args);
cache.put(args[0], retVal);
} else {
retVal = method.invoke(ctx, args);
return retVal;
} catch(InvocationTargetException oops) {
throw oops.getTargetException();
Ed <[email protected]> wrote:
Adarsh,
We agree it is a brilliant idea - now just to work out how to do it.
As you cannot always guarantee to be able to change the client code
you cannot use normal pooling techniques:
getObjectFromPool()
// do work
returnObjectToPool()
So, the client code needs an InitialContext. We can put in our own
Factory and intercept the getInitialContext() calls. This method
must
return class javax.naming.Context - therefore the only way I can see
to spot when the class is dereferenced is to extend the class and add
a finalize() method that notifies the factory.
The trouble I believe is that the class cannot be "rescued" in the
finalize() method (i.e. "I'm dying - take me back" ;-). If it simply
told the factory to add another one to its pool this would mean that
the new IC create "hit" would be in garbage collection (i.e. the
users
will pay somewhere along the line) - is this correct?
Anyone any ideas on a solution? I have discovered out code create
HUNDREDS of contexts in an hour and discards them very quickly. Be
nice to be able to cache them!
Cheers
Ed
"Adarsh Dattani" <[email protected]> wrote in message
news:<[email protected]>...
Ed,
This a brilliant idea. We are planning something similar too. We
first
want to create a pool of LDAP connections as apps make extensive
calls
to
LDAP. Did you check-out the object pooling api at Jakarta Commons.
It
deserves a close look.
http://jakarta.apache.org/commons/pool/index.html
Thanks,
Adarsh
"Ed" <[email protected]> wrote in message
news:[email protected]...
I have read the posts about caching initial context lookups and
have
implemented the solution and seen some benefits.
I am dealing with a third party application that I cannot change.
When I put my InitialContextFactory in the architecture I also
logged
how many getInitialContext() calls were being made - I was
absolutely
shocked - often 4+ per user transaction. I suspect that the code
gets
one, does a call and dereferences all over the place.
90% of InitialContexts had the same environment passed to the
getIC()
call so it struck me that what I should do is create a pool of IC,
and
in my factory just serve one from the pool.
So, the question is, what is the best way of detecting when the IC
has
been dereferenced so I know I can serve it again from my pool?
I presume this is a generic pool problem when you can't guarantee
that
your client's will be good citizens and call a close() method or
similar.
I've posted here as it is performance related; also, is there any
reason why what I am doing is not a good idea?
Can the client do something with the IC which means it is not
suitable
for use by another client? If so, can I detect this so I may
discard?
As always, many thanks in advance.
Presuming I can get it to work I will post the code so that we can
all
share ;-)
Cheers
Ed
Dimitri
Dimitri

JNDI initialContext hanging

Under a stress test load over around 100 users we seem to be able to hang
the WLS 5.1 SP6 server after only a few minutes. A thread dump shows all
execute threads waiting on the initialContext method, where we are
attempting to contact the JNDI service on another WLS 5.1 SP6 server.
Reducing the code down to a simple JSP doing nothing more than constructing
the initialContext and then closing it shows the same problem!
JDK : Sun 1_3_0
Anybody seem this or have any idea? Also have tried using a cached context
but then the problem seems to move to the EJB lookup or business method
invoke. Most strange but rather a show stopper for the scale we are looking
for from the application.

Will try to get a copy but I'm off site right now and don't have a copy to
hand. Of the execute threads all had stalled on Object.wait() with the chain
starting from either an initialContext() construction or lookup() method.
Reading around the JNDI Context I get the feeling (a) the service is
syncronised (b) should be called sparingly. In the case we are working with
the Provider_URL is another host.
Rob Woollen <[email protected]> wrote in message
news:[email protected]..
Can you post the thread dump?
-- Rob
Tony Symons wrote:
Under a stress test load over around 100 users we seem to be able to
hang
the WLS 5.1 SP6 server after only a few minutes. A thread dump shows all
execute threads waiting on the initialContext method, where we are
attempting to contact the JNDI service on another WLS 5.1 SP6 server.
Reducing the code down to a simple JSP doing nothing more thanconstructing
the initialContext and then closing it shows the same problem!
JDK : Sun 1_3_0
Anybody seem this or have any idea? Also have tried using a cachedcontext
but then the problem seems to move to the EJB lookup or business method
invoke. Most strange but rather a show stopper for the scale we arelooking
for from the application.--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com

Portal seems to cache RFC results

Hi,
we are calling an RFC in an R/3 4.6C server from an
EP6 SP9 (sneak preview) using JCA. The call is succesful,
but the portal seems to cache the call results; i.e. if
we change the data returned by the RFC the portal receives
the old values. If we restart the portal the returned data
changes, but only on the first call.
I suppose there is some setting for caching RFC results,
but I am not able to find it.
Thanks in advance.
Mattia

Here it is:
BAPI:
FUNCTION zep_test.
*"*"Local interface:
*" EXPORTING
*"     VALUE(RETURN) LIKE BAPIRET2 STRUCTURE BAPIRET2
*" TABLES
*"      T_AVVISI STRUCTURE ZLIST_AVVISI
DATA:
      l_wa_avvisi   LIKE LINE OF t_avvisi
CLEAR return.
CLEAR t_avvisi.
REFRESH t_avvisi.
* l_wa_avvisi-cdl    = 'E'.
* l_wa_avvisi-avvisi = 1.
* APPEND l_wa_avvisi TO t_avvisi.
* l_wa_avvisi-avvisi = 7.
* APPEND l_wa_avvisi TO t_avvisi.
* l_wa_avvisi-avvisi = 8.
* APPEND l_wa_avvisi TO t_avvisi.
* l_wa_avvisi-avvisi = 55.
* APPEND l_wa_avvisi TO t_avvisi.
* l_wa_avvisi-avvisi = 7.
* APPEND l_wa_avvisi TO t_avvisi.
* l_wa_avvisi-avvisi = 1.
* APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-cdl    = 'R'.
l_wa_avvisi-avvisi = 12.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 30.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 1.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 5.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 10.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 27.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-cdl    = 'M'.
l_wa_avvisi-avvisi = 13.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 7.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 8.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 10.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 2.
APPEND l_wa_avvisi TO t_avvisi.
l_wa_avvisi-avvisi = 34.
APPEND l_wa_avvisi TO t_avvisi.
return-type = 'S'.
ENDFUNCTION.
The component is a variation of the jca.SampleComponent.par I found either on SDN or in a note (sorry, I can't seem to find it anymore). I only
changed the doJca method (below).
public void doJca(IPortalComponentRequest request, IPortalRequestEvent event) {
    System.out.println("doJca()");
    Context ctx = null;
//    IConnectionFactory connectionFactory = null;
    IConnection client = null;
    ConnectionProperties prop = null;
    String rfm_name = "ZEP_TEST";
    String system_alias = request.getParameter("system");
    if (system_alias == null) {
               app.putValue(
                    "error",
                    "Couldn't establish a connection with a target system " + system_alias + ".");
               return;
    System.out.println("system_alias = " + system_alias);
    app.putValue("error", "");
    app.putValue("exportParams", "");
    app.putValue("system_alias", system_alias);
    try {
      // Obtain the initial JNDI context
      //   ctx = new InitialContext();
      // Perform JNDI lookup to obtain connection factory
      //   connectionFactory = (IConnectionFactory) ctx.lookup("EISConnections/SAPFactory");
      //   IConnectionSpec spec = connectionFactory.getConnectionSpec();
      //   ((Map) spec).put("client", "100");
      //      ((Map) spec).put("UserName", "");
      //      ((Map) spec).put("Password", "");
      //      ((Map) spec).put("logonmethod", "UIDPW");
      //      ((Map) spec).put("Language", "EN");
      //      ((Map) spec).put("ashost", "");
      //      ((Map) spec).put("sysnr", "01");
      //      IConnection client = connectionFactory.getConnectionEx(spec);
      IConnectorGatewayService cgService =
        (IConnectorGatewayService) request.getService(IConnectorService.KEY);
      try {
                    prop = new ConnectionProperties(request.getLocale(), request.getUser());
      } catch (Exception e) {
                    app.putValue(
                         "error",
                         "Couldn't establish a connection with the user " + request.getUser() + "." + e);
                    return;
      try {
                    client = cgService.getConnection(system_alias, prop);
      } catch (Exception e) {
                StringWriter wr = new StringWriter();
                e.printStackTrace(new PrintWriter(wr));
                    app.putValue(
                         "error",
                         "Couldn't establish a connection with a target system " + system_alias + "." + wr.toString());
                    return;
       * Start Interaction
      IInteraction interaction = client.createInteractionEx();
      System.out.println("Starting Interaction...");
      IInteractionSpec interactionSpec = interaction.getInteractionSpec();
      interactionSpec.setPropertyValue("Name", rfm_name);
       * CCI api only has one datatype: Record
      RecordFactory recordFactory = interaction.getRecordFactory();
      MappedRecord importParams = recordFactory.createMappedRecord("CONTAINER_OF_IMPORT_PARAMS");
      IFunctionsMetaData functionsMetaData = client.getFunctionsMetaData();
      IFunction function = functionsMetaData.getFunction(rfm_name);
      if (function == null) {
        app.putValue(
          "error",
          "Couldn't find " + rfm_name + " in a target system " + system_alias + ".");
        return;
       * How to invoke Function modules
      System.out.println("Invoking... " + function.getName());
      MappedRecord exportParams = (MappedRecord) interaction.execute(interactionSpec, importParams);
      app.putValue("exportParams", exportParams);
       * How to get structure values
      IRecord exportStructure = (IRecord) exportParams.get("RETURN");
      String columnOne = exportStructure.getString("TYPE");
      String columnTwo = exportStructure.getString("NUMBER");
      String columnThree = exportStructure.getString("MESSAGE");
      System.out.println(" RETURN-TYPE    = " + columnOne);
      System.out.println(" RETURN-CODE    = " + columnTwo);
      System.out.println(" RETURN-MESSAGE =" + columnThree);
       * How to get table values
      IRecordSet exportTable = (IRecordSet) exportParams.get("T_AVVISI");
      exportTable.beforeFirst(); // Moves the cursor before the first row.
      while (exportTable.next()) {
        String column_1 = exportTable.getString("CDL");
        String column_2 = String.valueOf(exportTable.getInt("AVVISI"));
        System.out.println(" COMPANYCODE_LIST-COMP_CODE = " + column_1);
        System.out.println(" COMPANYCODE_LIST-COMP_NAME = " + column_2);
       * Closing the connection
       interaction.getConnection().close();
      client.close();
    } catch (ConnectorException e) {
      app.putValue("error", e.toString());
      System.out.println("Caught an exception: n" + e);
      throw new RuntimeException(e);
    } catch (Exception e) {
      app.putValue("error", e.toString());
      System.out.println("Caught an exception: n" + e);
      throw new RuntimeException(e);
When I uncomment the commented section in the BAPI
(or I comment out some more of it), the result displayed
by the iView does not change until I restart the portal.
Thanks in advance!
Mattia

[WLS 9.2] Intermittent performance glitch creating InitialContext

Hi,
We are experiencing a peculiar problem with our WLS 9.2 installations: the time taken to create an InitialContext on a remote host has extremely variable performance.
The setup is that we have a gateway server running WLS 9.2 on Solaris 10 that is sends JMS messages to a number of application servers (all running WLS 9.2/Solaris 10). This is done, in the usual fashion, by creating an InitialContext from which we can lookup the ConnectionFactory and Queue. The gateway server is very sensitive to delays in sending the JMS message and any message that cannot be delivered within a specified time triggers a failover scenario and the message is routed to another server.
Investigation of the what was causing the failover to trigger showed that it is that the creating of the InitialContext that occassionally takes significantly longer than we expected. We set up a simple test in isolation to our system that schedules a task every 30 seconds that only creates an InitialContext and times how long it takes. Here are the stats from two sample runs:
Run 1
Mean: 13 ms
Average: 55.54 ms
Min: 11ms
Max: 5086 ms (5 s)
Sample size: 1566
Run 2
Mean: 22 ms
Avgerage: 139.7 ms
Min: 14 ms
Max: 11444 ms (11 s)
Sample size: 1733
Interestingly, when we run this same test from a Windows-based WLS 9.2 installation, the time reported by the test is 0 ms. I can only assume that there is an underlying
We are working around the problem by creating a pool of message dispatchers that already have an initialised InitialContext but we still run into this problem when the pool needs to grow and additional dispatchers are created.
A smaller scale test on using a Windows-based gateway connection to the same Solaris-based application server did not experience the sample problem.
Any ideas?
The code used for the test:
public class InitialContextTest implements Runnable {
    private static final Logger LOG = Logger.getAnonymousLogger();
    private Hashtable<String, String> _environment = new Hashtable<String, String>();
    public void run() {
        final long start = System.currentTimeMillis();
        weblogic.security.Security.runAs(new Subject(), new PrivilegedAction<Void>() {
            public Void run() {
                InitialContext context = null;
                try {
                    context = new InitialContext(_environment);
                } catch (NamingException e) {
                    LOG.log(Level.SEVERE, "test: Cannot create initial context", e);
                } finally {
                    try {
                        if (context != null) {
                            LOG.log(Level.INFO, "test: Closing initial context");
                            context.close();
                    } catch (NamingException e) {
                        LOG.log(Level.SEVERE, "test: Cannot close initial context", e);
                return null;
        final long end = System.currentTimeMillis();
        LOG.log(Level.INFO, "test: t=" + (end - start));
    public void setEnvironment(Map<String, String> environment) {
        _environment.putAll(environment);
}Edited by: Marcus Edwards on Oct 16, 2009 5:16 PM
remove standard deviation figures at they are invalid

Hi,
I don't know what the issue is, but I imagine there could be any number of causes. Overwhelmed DNS servers, network issues, or a even a very long GC. Or there could be a competing process somewhere local or remote that consuming 100% CPU intermittently (which would freeze out or slow other work).
In case you don't already know:
1 - Contexts are thread safe.
2 -There's usually no need to have multiple contexts if they all resolve to the same remote JNDI host, or even the same cluster (usually no performance benefit).
3 - Multiple WebLogic Java contexts on a local JMS that all connect to the same remote JVM will all multiplex over the same socket. When a new context is created, WebLogic sets up a new network connection, checks to see if the local JVM already is talking to the same server (by comparing data returned from the new connection to data from current connections), and, if so, tears down the new network connection and routes traffic for the new Context over the old pre-existing connection.
4 - As you've already discovered, its best practice to cache contexts. In addition, it's best practice to cache JNDI lookup results, as well as JMS connections, sessions, producer, and consumers.
5 - The test you posted below has a memory leak: it should call context.close() when its done with the context.
Tom

WEB u2013 I cache issue.

We have BO XI 3.1 PF 1.7 and SAP BW 7.0 SP 18
We are facing strong caching issue with WEB- I XI 3.1 , what we observed is it cache previously fetched data and does not recognize data been updated in BW Infoprovider ( in our case we have BEx query on Direct update DSO )
I have tried u2013
1. I made caching inactive for that BEx query in BW side.
2. I have check caching setting in BO , they are not helping me much to in active cache in BO
On executing BEx query in BW, I have checked RSRT cash monitor; the query result is not getting cached, and get up-to-date data. Query works perfectly file.
Also observed Events in RSDDSTAT_OLAP table, I could find very well Event 9000. This shows me that BEx query hits database and bring data back.
When I execute BO report on the top of same BEx query, I do not get up to date data , it shows me previously fetched data and does not recognize data been updated in BW.
Now question is where this data being getting cashed , and how to make that inactive to make sure I do get up to date data in WEB-I .
Many thanks for your kind response.
Regards
Ashutosh D

HI Ashutosh,
This would be stored in the C:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\Data\servername_6400\storage folder. Try renaming this folder and then testing again. If this allows for updated records, then that proves that the Webi Processing Server is getting the cached data from this directory.
There are also a few settings you can try to disable in the Webi Processing Server settings within the CMC:
Disable cache Sharing (Checked)
Enable Real-Time Caching (Unchecked)
Enable Document Cache (Unchecked)
Cache Timeout (1 min) - sets the cache to expire after 1 min.
Try playing with these settings and see if that resolves the issue.
Thanks
Jb

InitialContext caching previous lookups?

Similar Messages

Maybe you are looking for