Caching & thread in ejb

Hi,
In order to gain better performance in our current application
we need to cache some data in both web and ejb tier. Data that
we need to store is not client specific (global data) and rarely
changes. In web tier we cache this kind of data in
ServletContext. We are trying to find a way to store data in ejb
tier. In our design we use only Stateless Session Beans in which
we have JDBC calls to access DB. In particular case we need to
get some data from DB that is specific to current date. So,
ideally we would like to fetch that data when ejb server starts,
store it and refresh it at midnight. So, if this was not an ejb
application we would probably use Singleton to store this data
and have some thread that will wake up at 0:00 to refresh
state of the singleton object.
I would really appreciate any suggestion.
Regards,
Ilija

Making it ReadOnly will ensure that ejbLoad is not called. Also,
if you use 6.1, generated home implements weblogic.ejb.Caching[Local]Home,
which makes invalidations (local and in cluster) easier.
Ilija <[email protected]> wrote:
Thanks. I have few more questions regarding caching. I am not
sure if what I am doing is completely correct.I have entity ejb
with bean managed persistence that caches data. Data is
retrieved from multiple tables and there is no real bean dentity
in DB.
ejbFindByPrimaryKey does not go to DB, it simply returns passes String value(primary
key).
ejbLoad() loads everything from DB and initialize instance of
the bean.
ejbRemove() does not do anything.
ejbStore() does not do anything.
ejbActivate() does not do anything
ejbPasivate does not do anything
invalidate() throws RemoteException
baean is deployed with NotSupported transaction attribute.
Everything seems to be working OK. I am wandering if there is any
benefits of making this bean as a read only since ejbStore does
not do anything in my case.
Dimitri Rakitine <[email protected]> wrote:
That's what I did - I wrote my own implementation of JMX timer.
Anyway, this deprecation of time services is a little confusing. I saw
2 replacement recommendations in WebLogic docs (both unacceptable) -
use
java.util.Timer, or purchase Flux.
On the other hand, time services work just fine in 6.1.
Ilija <[email protected]> wrote:
Thanks Dimitri. I see that weblogic deprecated api for trigger andI am curios
if it would be correct to have my own scheduler in web tier that willinvalidate
this ejb.
Dimitri Rakitine <[email protected]> wrote:
Schedule a trigger which will invalidate RO bean(s) at midnight ?
Ilija <[email protected]> wrote:
Thank you for your suggestions Rob. I guess read only entity beansare very close
to what we need. The only issue I can see is the fact that we haveto update state
of this bean at midnight. Since we are not supposed to create threadin ejb container
what do you suggest as a way to do that?
Regards,
Ilija
Rob Woollen <[email protected]> wrote:
Ilija wrote:
Hi,
In order to gain better performance in our current application
we need to cache some data in both web and ejb tier. Data that
we need to store is not client specific (global data) and rarely
changes. In web tier we cache this kind of data in
ServletContext.I would suggest that you use the JSP Cache tags and Cache filters
in
WLS for caching in the web tier. They will allow you to cache pages
or
page fragments.
We are trying to find a way to store data in ejb
tier. In our design we use only Stateless Session Beans in which
we have JDBC calls to access DB. In particular case we need to
get some data from DB that is specific to current date. So,
ideally we would like to fetch that data when ejb server starts,
store it and refresh it at midnight. So, if this was not an ejb
application we would probably use Singleton to store this data
and have some thread that will wake up at 0:00 to refresh
state of the singleton object.
Take a look at Read-Only entity beans.
-- Rob
I would really appreciate any suggestion.
Regards,
Ilija
Dimitri--
Dimitri
Dimitri

Similar Messages

  • Why oc4j allows to use File IOs and manage thread in EJB?

    I don't understand why Oc4j 9.0.2 allows to use File IO and create thread in EJBs? These things should be denied in its implemenation.

    Any chance I can get this data?

  • Combining the fixed and cached thread pools

    Is there a way to 'combine' the behavior of cached and fixed thread pools ? I have a requirement where
    - at startup, I need to execute a fixed number of short-lived tasks at the background
    - after startup, on demand, I need to run one short-lived task at a time
    If I use a fixed thread pool for my startup processing, it creates the fixed number of threads to process the tasks. But subsequently, those many threads are not required since my task submission is going to be one at a time. The remaining (n-1) threads therefore are really sitting idle & useless.
    If I use a cached thread pool, then I cannot constrain the number of threads to run at startup (since it creates one for each task). Though it ends up taking those threads out after they are idle for a fixed period. But I'm worried that it might create many threads and possibly slowing down the startup ?
    Is there a way to create a pool with a fixed number of threads but 'remove' a set of threads when they are idle ?
    TIA

    v_bala wrote:
    Thanks. The SynchronousQueue worked as expected. But I tried a LinkedBlockingQueue with size 1 hoping that would cause the second task submission to cause a new thread creation. It didn't. Instead it queues up the request (maybe the doc in ThreadPoolExecutor says that when it mentions "If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread"). I suppose if I were to try another it would create another thread ? (I was testing with only two tasks - the first one ended up creating a thread for the task and the next got queued since the queue capacity is 1)yes, the TPE will not start adding threads until the queue starts rejecting them. kind of odd in my opinion, but that's how it works.
    Btw, that was an interesting idea to add a task that scale the core pool number down ! Currently it comes back down to just the one thread (my core pool size is one) after the idle timeout but your idea may give me a slightly better response since it will scale down the core pool size quicker....I suppose if there was a task submission before that idle time there maybe a performance hit (but I don't anticipate that in my case )?actually, that won't scale things down any faster. changing the core pool size will not ditch the other threads immediately, they will still stick around until they idle timeout. changing the core pool size allows you to not worry about the queue implementation (the first solution). you can set the initial core pool size to your "max" size on startup, then drop it down for the normal processing, all the while using a linkedblockingqueue of unlimited size.

  • Creating Threads in EJBs

    Hi,
    I know that you are not allowed to create threads inside EJBs. However, can an EJB call some java networking code that creates threads for its purpose?
    In other words, how far does this prohibition on threads go? You can't even call some code that creates threads inside an EJB or is it that you just can't create threads inside the EJB class itself?
    Thanks,
    Y.

    I know that you are not allowed to create threads
    inside EJBs. However, can an EJB call some java
    networking code that creates threads for its
    purpose?Although the specs don't allow you, they don't completely rule out the possibility.
    In other words, how far does this prohibition on
    threads go? You can't even call some code that
    creates threads inside an EJB or is it that you just
    can't create threads inside the EJB class itself?
    http://www.theserverside.com/discussions/thread.tss?thread_id=31118This discussion should throw some light.

  • Thread in EJB

    Hi all,
    I am just wondering if I can use Thread.sleep to pause a session bean and wake it up later?
    I know that J2EE takes care multithreading but AM I allowed/forbiddened to do something?
    Thanks in advance,
    Joe

    As Maris says, it usually works. But EJB spec forbids thread management because the container automatically manages lifecycle. It means that you have no guarantee that it will work as you think it will. Did you think about what happens to the threads when the EJB is passivated? I used threads in EJBs in JBoss and it worked but I decided to move the feature to the web container, because I expect that it only works in simple, predictable situations, and anyway it is certainly not portable.
    In other words, avoid it if you can :) Maybe you can move the forking to a web component or a resource adapter...
    Bruno
    http://www.practicalsoftwarearchitect.com

  • Caching in an ejb

    I want a web service that acts as a proxy/adapter to an ejb. The problem is the web service caches its data and I want to move that cache to the ejb. How do I implement a custom cache in an ejb? Are there any patterns or a variation of a pattern to facilitate this implementation?
    Thanks,
    Matthew

    My Thoughts
    Did you ever think about the sceanrio's like clustering your application for performance?
    If you imlpement your custom cache it will not work and its will be very tedious to write codes to update the cache in the cluster and come across fail over's and fault tolerance.
    The best is to persist your Objects and leave the cache to the Application Container you use. JBoss provides this, not sure about the other app servers.
    You can try apache JCS if you would like to customize the cache.
    :D

  • Cache coordination for EJB on Oracle application server

    I have an enterprise application using Eclipselink that runs on a 2 node clustered OAS instances. I need to set up cache coordination between the two nodes. Can someone please point me to documentation for this setup? I am using v1.2 Eclipselink on 10.1.3.3 OAS.
    Thanks.

    185743,
    In order to access an Enterprise JavaBean, you need to "login" to the EJB container. The login name and password are usually supplied via the "SECURITY_PRINCIPAL" and "SECURITY_CREDENTIALS" properties (from the Context interface).
    The error message you are getting -- "Connection refused" -- usually indicates that you have supplied the wrong values for at least one of those properties. There are a number of ways to define these properties, and the one that you require depends on the type of client you are using: either a Web client, or a java client.
    Since you did not supply the part of your code that is causing the problem, I cannot help you further.
    Good Luck,
    Avi.

  • Threads in EJB

    Hi,
    Can we make our Enterprise Bean, implement Runnable Interface thereby can we invoke a new Thread within the Enterprise Bean?

    Can we make our Enterprise Bean, implement Runnable
    Interface thereby can we invoke a new Thread within
    the Enterprise Bean?There are reasons why the EJB spec makes that illegal.
    And if you think about it, you'll find that interfering with the container's ability to control threads and more generally its runtime environment might not be a good idea.
    By passing through code that the container expects to have full control over, you'll be creating concurrency issues, as well as compromising the container's task of managing its components lifecycle. In particular, the container will have difficulty in passivating your bean, since it will have no control over your thread or freeing the resources held by your thread..

  • Multi Threading in EJB by sending requests to JDBC or JMS queue

    Hi,
    I know that multi-threading is not permitted on EJB, but I'm planning an application which has to send a copule of requests to another system in parallel. So the EJB should be talking to any number of other systems at one time.
    In an application I would simply create some threads, and that's it. With EJB this is not possible, so I've come up with the following idea:
    A Queuing system will be implemented. This can be a simple table in a database or a message bean (JMS-Java Message Service). In both cases request objects have to be serialized into byte streams and stored as a Binary Object (e.g. Oracle BLOB) in the database or attach somehow to the JMS message.
    Some sort of queue processor looks at the queue, deserializes the requests, does something and sends back a response (again by serialization and through db or jms).
    Technically the db solution should work, I've been doing ths (de)serialization of java objects into an oracle blob, and it works. Creating a process which scans a database should also work, and with timestamps I can implement a queue.
    With JMS I'm not that sure, mainly because I'm not familiar with it :-). But as far as I know some JMS vendors (I do not remember who) are using database for messaging anyway.
    Any comments ?
    Thanks

    As I understand JMS, the database is used for persistence of messages before they are acknowledged.
    If persistence is turned on, once a message arrives on the queue, the message object is serialized and stored in the database with an appropriate primary key.
    When the consumer calls the receive() method the Message Object is sent to the consumer, when this acknowledged the corresponding entry is removed from the database.

  • Caching EJB references

    Hi all,
    I was wondering if anyone could give me a conclusive explanation regarding the caching options for EJB objects(SLSB, and Entity Beans), both home/remote and localHome/local.
    I have read a lot of various EJB documentations including a fairly thorough look into the spec, and have about 2 years of practical expirience with EJBs.
    The matter that is still vague to me after all this time is the matter of caching and reusing EJB references. practical expirience and some documentation lead me to believe that caching an EJB reference of any kind is hazardous. From what I saw the spec never adresses this issue in a straightforward conclusive manner. It does discuss some failover scenarios and the use of EJB handles as both optionally a persistent reference and a "long living" refernce, but never in a context that is "spec mandatory" and "encapsulates" the whole picture.
    Now, there is no fundamental difference between caching a reference or using one that is locally scoped in a single method, except the time it is expected to be "alive", which is, by definition, a relative and unmeasurable matter.
    Theoretically, I am sure there is no problem implementing references, which are actually client "proxies", stubs, in a way that will not be dependent of an exact instance, but rather on an abstract EJB ID(which may indeed cause a performance overhead).
    Anyway, I don't want to get into implementation details, I am simply looking for a clear explanation about the matter of "long living" references, and what is mandatory by EJB specification.
    Thanks for any insights....
    I also crossposted to EJB forum -> http://forum.java.sun.com/thread.jsp?forum=13&thread=538526&tstart=0&trange=15

    A locally scoped reference is only on the stack while the cached reference is on the heapOf course, but in the context of what I'm talking about here, that doesn't really matter. The point is that in both cases there is a reference to an EJB object/home, that is used for a longer/shorter time.
    I think the main reason for not caching the references is that is interfere's with the server's ability to manage it's resources. OK, sounds reasonable enough. So why doesn't the specification provide clear rules, even restrective ones that say no caching can be applied? Looks to me as if it would be safe to say that home objects for example are safe to cache working with any EJB server as long as the EJB server isn't restarted. Why isn't it written anywhere?
    It always refers to Handles as "long living" references. How can one measure "long"?
    Now, I may have gotten the wrong picture. Maybe there are some widely agreed issues on this matter, for example that caching SLSB as you've mentioned, and home objects is always safe in the scope of an EJB server life time(from the point in which it starts to the point it goes down).
    The thing is, where ever I looked I saw different strategies, and never it was clear what exactly they came to solve. For instance, an EJBHome service locator that caches the home object as is, vs. a service locator that caches the home handle.

  • EJB Facade + DAL + DTO Caching

    I'm pretty new with EJB and I'm trying to architect a simple application using it. I'm using an Application Server that potentially may span into multiple servers with clustering. I'm building my business layer using EJB so that the AS can handle server clustering automatically. The EJB objects actually only serves as a facade to my DAL using TDG and DTO objects. I can get this setup to work, however it come across to my mind that I might have a problem with multiple clustering servers when I'm building my own caching scheme for my DTO objects. The problem is because in the scenario with multiple servers, the cache object may live (/span) to multiple servers also. Now, if I use POJO to build the cache, (I'm only assuming here) then theres a possibility that my cache will be used on multiple instances on multiple servers. If I store a DTO object on one of my cache on a specific server then when a client request that object and the request accidentally routed through another server, then the caching system wont recognize the DTO object cached in another server and would try to retrieve the object from DB and put it in the cache specific to that server. That would cause my caching system fails and, worse, I'd have multiple copies of the same object which, of course, will be disastrous.
    I havent really figured out how to overcome this problem, maybe building my cache object using EJB also could save the problem so that every request would have to be handled via JNDI, but I still couldn't figure out how will I be able to resolve if an object already instanced in another server and what about the penalty from doing such a thing. Can anyone give me guidances or suggestions or point me where I should look for informations?
    Edited by: punkouterz on Oct 15, 2007 5:08 PM
    Moved to a more appropriate forum : http://forum.java.sun.com/thread.jspa?threadID=5226379

    I'm pretty new with EJB and I'm trying to architect a simple application using it. I'm using an Application Server that potentially may span into multiple servers with clustering. I'm building my business layer using EJB so that the AS can handle server clustering automatically. The EJB objects actually only serves as a facade to my DAL using TDG and DTO objects. I can get this setup to work, however it come across to my mind that I might have a problem with multiple clustering servers when I'm building my own caching scheme for my DTO objects. The problem is because in the scenario with multiple servers, the cache object may live (/span) to multiple servers also. Now, if I use POJO to build the cache, (I'm only assuming here) then theres a possibility that my cache will be used on multiple instances on multiple servers. If I store a DTO object on one of my cache on a specific server then when a client request that object and the request accidentally routed through another server, then the caching system wont recognize the DTO object cached in another server and would try to retrieve the object from DB and put it in the cache specific to that server. That would cause my caching system fails and, worse, I'd have multiple copies of the same object which, of course, will be disastrous.
    I havent really figured out how to overcome this problem, maybe building my cache object using EJB also could save the problem so that every request would have to be handled via JNDI, but I still couldn't figure out how will I be able to resolve if an object already instanced in another server and what about the penalty from doing such a thing. Can anyone give me guidances or suggestions or point me where I should look for informations?
    Edited by: punkouterz on Oct 15, 2007 5:08 PM
    Moved to a more appropriate forum : http://forum.java.sun.com/thread.jspa?threadID=5226379

  • ClassNotFoundException in EJB's and Threads (Classloader issue)

    A very interesting bug has cropped up in WebLogic 6.1. When a J2EE
    application packaged appropriately, a client application running in a
    user-created Thread will always throw a ClassNotFoundException when
    attempting to get back a user-created object from an EJB living on
    another cluster. This error does not happen when the call is being made
    from outside a Thread.
    Sounds strange, I know, so I'll try to give everyone as much detail as
    possible so they can avoid this bug, and so that the folks at BEA can
    fix it.
    * A java class running inside a clustered WL6.1 server is attempting to
    reference an EJB on another clustered WL 6.1 server. Accessing the bean
    is not a problem, the client class is able to obtain a remote reference
    to the bean and make method calls on it. Calling a method causes the
    following stack trace:
    2002-01-11 10:36:57,331 [Thread-4] ERROR
    wpni.app.mywp.display.DisplayJobs$JobsMonitor -
    wpni.app.mywp.display.DisplayJobs$JobsMonitor.run: Error checking Jobs
    status.
    java.rmi.UnmarshalException: failed to unmarshal class
    wpni.app.jobs.JobsData; nested exception is:
    java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This
    error could indicate that a component was deployed on a cluster member
    but not other members of that cluster. Make sure that any component
    deployed on a server that is part of a cluster is also deployed on all
    other members of that cluster
    java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This error
    could indicate that a component was deployed on a cluster member but
    not other members of that cluster. Make sure that any component deployed
    on a server that is part of a cluster is also deployed on all other
    members of that cluster
    at
    weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:146)
    at
    weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.java:211)
    at
    weblogic.common.internal.ChunkedObjectInputStream$NestedObjectInputStream.readClassDescriptor(ChunkedObjectInputStream.java:290)
    at
    java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:906)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
    at
    java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
    at
    weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:107)
    at
    weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:115)
    at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:56)
    at
    weblogic.rmi.internal.BasicRemoteRef.unmarshalReturn(BasicRemoteRef.java:230)
    at
    weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:254)
    at
    weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
    at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
    at $Proxy140.getJobsData(Unknown Source)
    at
    wpni.app.mywp.display.DisplayJobs$JobsMonitor.run(DisplayJobs.java:48)
    at java.lang.Thread.run(Thread.java:484)
    * The class that is not found (JobsData) is definitely in the EAR file
    on both the client cluster and the server cluster, and in the
    appropriate location.
    * When we attempted to run the code outside of a Thread, everything
    worked perfectly, so it was definitely the Thread that was causing the
    problem.
    * Deploying the EJB on the client cluster did not do anything to solve
    the problem.
    * Adding the JobsData to the System CLASSPATH at the startup of the
    WebLogic server DID solve the problem. But of course that defeats the
    purpose of packaging everything in the EAR file.
    So, the conclusion seems to be that when DisplayJobs$JobsMonitor kicked
    off the Thread, the Thread should have been created in either the WAR's
    classloader or the JAR's classloader (wouldn't matter, since the
    JobsData class is in the JAR's classloader, which is a parent of the
    WAR's classloader). But instead, the Thread is being created in the
    System classloader, which can't find the JobsData class!
    We believe that any Thread created by a class living within an EAR's
    classloader should remain within that same classloader, and not migrate
    to any other classloader, in order to avoid situations like this. We're
    opening a case with BEA to attempt to get this resolved. In the
    meantime, we recommend to developers that if they have to make
    cross-cluster RMI calls from inside user-created Threads, that they only
    attempt to receive primitive types or standard JDK objects. Otherwise,
    you'll have to add the classes to the System CLASSPATH at startup of the
    WebLogic instance.
    Thanks,
    Erin
    * "[White House spokeperson Ari] Fleischer
    * warned Democrats this morning against
    * investigations into the Bush administration's
    * dealings with Enron. 'The American people
    * are tired of partisan witch hunts and endless
    * investigations,' he said." [Ed.: Uh... ]
    * www.washingtonpost.com/wp-dyn/articles/A25159-2002Jan10.html
    * Erin Reid Myers, Chief Architect
    * WashingtonPost.Newsweek Interactive
    * [email protected]
    * Work: (703) 469-3154
    * Cell: (703) 725-3050
    [att1.html]

    Things can go seriously wrong if your application uses user threads (violating
    EJB spec programming restrictions and BEA recommendations).
    I'm curious, does it work if you enable network classloading on the server
    which invokes remote EJB (in config.xml -
    <Server NetworkClassLoadingEnabled="true" ...
    </Server>
    Erin Reid Myers <[email protected]> wrote:
    A very interesting bug has cropped up in WebLogic 6.1. When a J2EE
    application packaged appropriately, a client application running in a
    user-created Thread will always throw a ClassNotFoundException when
    attempting to get back a user-created object from an EJB living on
    another cluster. This error does not happen when the call is being made
    from outside a Thread.
    Sounds strange, I know, so I'll try to give everyone as much detail as
    possible so they can avoid this bug, and so that the folks at BEA can
    fix it.
    * A java class running inside a clustered WL6.1 server is attempting to
    reference an EJB on another clustered WL 6.1 server. Accessing the bean
    is not a problem, the client class is able to obtain a remote reference
    to the bean and make method calls on it. Calling a method causes the
    following stack trace:
    2002-01-11 10:36:57,331 [Thread-4] ERROR
    wpni.app.mywp.display.DisplayJobs$JobsMonitor -
    wpni.app.mywp.display.DisplayJobs$JobsMonitor.run: Error checking Jobs
    status.
    java.rmi.UnmarshalException: failed to unmarshal class
    wpni.app.jobs.JobsData; nested exception is:
    java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This
    error could indicate that a component was deployed on a cluster member
    but not other members of that cluster. Make sure that any component
    deployed on a server that is part of a cluster is also deployed on all
    other members of that cluster
    java.lang.ClassNotFoundException: wpni.app.jobs.JobsData: This error
    could indicate that a component was deployed on a cluster member but
    not other members of that cluster. Make sure that any component deployed
    on a server that is part of a cluster is also deployed on all other
    members of that cluster
    at
    weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:146)
    at
    weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.java:211)
    at
    weblogic.common.internal.ChunkedObjectInputStream$NestedObjectInputStream.readClassDescriptor(ChunkedObjectInputStream.java:290)
    at
    java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:906)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
    at
    java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
    at
    java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
    at
    weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:107)
    at
    weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:115)
    at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:56)
    at
    weblogic.rmi.internal.BasicRemoteRef.unmarshalReturn(BasicRemoteRef.java:230)
    at
    weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:254)
    at
    weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:220)
    at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
    at $Proxy140.getJobsData(Unknown Source)
    at
    wpni.app.mywp.display.DisplayJobs$JobsMonitor.run(DisplayJobs.java:48)
    at java.lang.Thread.run(Thread.java:484)
    * The class that is not found (JobsData) is definitely in the EAR file
    on both the client cluster and the server cluster, and in the
    appropriate location.
    * When we attempted to run the code outside of a Thread, everything
    worked perfectly, so it was definitely the Thread that was causing the
    problem.
    * Deploying the EJB on the client cluster did not do anything to solve
    the problem.
    * Adding the JobsData to the System CLASSPATH at the startup of the
    WebLogic server DID solve the problem. But of course that defeats the
    purpose of packaging everything in the EAR file.
    So, the conclusion seems to be that when DisplayJobs$JobsMonitor kicked
    off the Thread, the Thread should have been created in either the WAR's
    classloader or the JAR's classloader (wouldn't matter, since the
    JobsData class is in the JAR's classloader, which is a parent of the
    WAR's classloader). But instead, the Thread is being created in the
    System classloader, which can't find the JobsData class!
    We believe that any Thread created by a class living within an EAR's
    classloader should remain within that same classloader, and not migrate
    to any other classloader, in order to avoid situations like this. We're
    opening a case with BEA to attempt to get this resolved. In the
    meantime, we recommend to developers that if they have to make
    cross-cluster RMI calls from inside user-created Threads, that they only
    attempt to receive primitive types or standard JDK objects. Otherwise,
    you'll have to add the classes to the System CLASSPATH at startup of the
    WebLogic instance.
    Thanks,
    Erin
    * "[White House spokeperson Ari] Fleischer
    * warned Democrats this morning against
    * investigations into the Bush administration's
    * dealings with Enron. 'The American people
    * are tired of partisan witch hunts and endless
    * investigations,' he said." [Ed.: Uh... ]
    * www.washingtonpost.com/wp-dyn/articles/A25159-2002Jan10.html
    * Erin Reid Myers, Chief Architect
    * WashingtonPost.Newsweek Interactive
    * [email protected]
    * Work: (703) 469-3154
    * Cell: (703) 725-3050
    Dimitri

  • EJB Cache

    Hi!
    I am having trouble figuring out how to do sessions in web services. For this porpouse I would like to use a cache in an EJB container...
    How could I make this cache, so that there is only one instance per cluster???

    Thanks swatdba,
    But I am trying to keep my app portable.
    I think I am going to do a singleton.
    Better to have one cache per VM rather not have any at all.

  • Urgent - calling EJB methods from thread

    Dear all
    I am aware of EJB spec that does not permit developer managed threads within EJB components. However, I need to call EJB methods from my own thread. Hence, it there any way to to call EJB methods from developer managed thread ?? If yes, please advice me, thanks in advance and your help will be appriciated.
    Hava a nice day

    You can call EJB's from your threads. Your thread will act as the client and the call will to EJB will be same as any other client invoking EJB's. Hope I understand your question !.

  • Caching on ejb container using Oracle 9i Application server

    Hi,
    can we cache on the ejb container in Oracle application server ?
    if so, whats the methodology ?
    Regards,
    Murali

    Can you explain exactly what you want to cache? The complete container: no makes no sences. Objects in the container, makes sences but in case of CMP the entites are already cached.
    Can you provide more information what you want to achieve?

Maybe you are looking for