Caching Session Beans

Is there any way to cache Stateless-session beans? We have the following
set up in the descriptor file:
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>statelessSession</ejb-name>
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>3000</max-beans-in-free-pool>
<initial-beans-in-free-pool>3000</initial-beans-in-free-p
ool>
</pool>
</stateless-session-descriptor>
<jndi-name>ejb20-statelessBean</jndi-name>
</weblogic-enterprise-bean>
for some reason, the bean is loaded as specified, but is being called from
disk for each process, not from the pool/cache.
Any help would be appreciated.
Thanks

I'm not sure that I understand your question.
For stateless session beans, we keep a pool of instances. When you make a
method call, we grab an instance from the pool. When the method call
finishes, we return it to the pool.
There's probably no reason to set this value to 3000. Unless you recursively
call your own instance, you'll never use more slsb instances than you have
execute threads in the server. The default max-beans-in-free-pool value
gives you the maximum parallelism.
-- Rob
[email protected] wrote:
Is there any way to cache Stateless-session beans? We have the following
set up in the descriptor file:
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>statelessSession</ejb-name>
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>3000</max-beans-in-free-pool>
<initial-beans-in-free-pool>3000</initial-beans-in-free-p
ool>
</pool>
</stateless-session-descriptor>
<jndi-name>ejb20-statelessBean</jndi-name>
</weblogic-enterprise-bean>
for some reason, the bean is loaded as specified, but is being called from
disk for each process, not from the pool/cache.
Any help would be appreciated.
Thanks

Similar Messages

  • Stateful Session Beans are not passivated / serialized when cache idle time

    Technology: Sun Application Server version 7.0.0_01; JDK 1.4.1; developed on Windows 2000; Tested on Sun Solaris.
    Initial error on Sun Solaris:
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: Exception in thread "service-j2ee-25" org.omg.CORBA.OBJ_ADAPTER: vmcid: SUN minor code: 1015 completed: No
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.GenericPOAServerSC.preinvoke(GenericPOAServerSC.java:389)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.initServant(ServantCachePOAClientSC.java:112)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.setOrb(ServantCachePOAClientSC.java:95)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.createDelegate(CDRInputStream_1_0.java:760)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.internalIORToObject(CDRInputStream_1_0.java:750)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_Object(CDRInputStream_1_0.java:669)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:890)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:884)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_abstract_interface(CDRInputStream.java:307)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:228)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:381)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:318)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.getStub(IIOPHandleDelegate.java:58)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.readEJBObject(IIOPHandleDelegate.java:38)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.ejb.portable.HandleImpl.readObject(HandleImpl.java:91)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObject(Native Method)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1298)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.inputObject(IIOPInputStream.java:908)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:261)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:247)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:209)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:981)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_value(CDRInputStream.java:287)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.javax.rmi.CORBA.Util.copyObject(Util.java:598)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.rmi.CORBA.Util.copyObject(Util.java:314)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.ejb._NodeMaint_Stub.getHandle(Unknown Source)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanProxy.checkBeans(NMAViewBeanProxy.java:631)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.html.NMAStandardButton.handleRequest(NMAStandardButton.java:143)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanBase.handleRequest(NMAViewBeanBase.java:1573)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.dispatchInvocation(ViewBeanBase.java:824)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:637)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler(ViewBeanBase.java:595)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:772)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:446)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:324)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.ViewServlet.doPost(ViewServlet.java:243)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:158)
    [10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
    The above error caused the server to use all available memory and required a reboot to proceed.
    Subsequent testing against the Sun Appliucation Server 7 on Windows 2000 dev environment using the Sun Studio IDE for debugging and trace statements inserted in the code indicate that the Application Server is removing the Stateful Session Beans when they time out without an ejbPassivate event and without serializing the beans to the data-store. cache-idle-timeout-in-seconds set to 180 and removal-timeout-in-seconds set to 1800.
    The server.log indicates that the beans are timing out:
    [19/Aug/2004:18:15:10] WARNING ( 1664): [NRU-com.telstra.nodeman.ejb.AddressMaintBean]: IdleBeanCleanerTask finished after removing 2 idle beans
    Trace statements inserted in ejbPassivate do not appear in the log.
    It is my understanding that the above timeout should have caused an ejbPasssivate and serialization of the beans.
    The beans have been validated using Sun Java Studio Enterprise 6 with 'EJB validate'.
    My reading of the problem is that the beans are not being serialized and the error occurs when the application attempts to reference (getHandle) the bean after timeout.
    Any suggestions would be appreciated.

    Thanks Thorick.
    I am using NRU caching. WL 7.0 SP2.
    I have not defined idle-timeout-seconds in my weblogic-ejb-jar.xml. As I understand
    the default value for this is 600secs. So the ejbs should be removed after this
    time. Below is the
    weblogic-ejb-jar.xml that I am using.
    <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
    'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>
    <!-- Generated XML! -->
    <weblogic-ejb-jar>
    <weblogic-enterprise-bean>
    <ejb-name>Cart</ejb-name>
    <stateful-session-descriptor>
    <stateful-session-clustering>
    <home-is-clusterable>true</home-is-clusterable>
    <replication-type>InMemory</replication-type>
    </stateful-session-clustering>
    </stateful-session-descriptor>
    <transaction-descriptor>
         <trans-timeout-seconds>
              60
         </trans-timeout-seconds>
    </transaction-descriptor>
    <jndi-name>CartHome</jndi-name>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>
    "thorick" <[email protected]> wrote:
    >
    The idle-timeout-seconds property controls the timeout/removal behavior.
    which stateful session cache type are you using ? LRUCache or NRUCache

  • How can i design a EJB application using session Beans?

    Hello,
    I am designing a Find application using EJB. Here a user is prompted a search page, where he can enter the search criteria's. Then on click of submit, the query is formed at the server side depending on what criteria's were selected. Then a jdbc query is performed and the results are returned back to the user. Here no session is maintained for the users. Can anyone suggest me how to design this application using EJB. Should i use entity beans for this or session beans will suffice? Should the jdbc query be performed in the bean itself or should it be outside in a helper class? Please kindlu suggest me the design for this application...
    Regards,
    Subbu

    Hi,
    First of all, I'm unable to figure out why you need to use EJB for this scenario. You can write a helper class to frame and execute the query.
    If you really want to use EJB, then I suggest you use a stateless Session Bean with transaction attribute as TX_NOT_SUPPORTED. From the session bean, you can call the helper class. But, by avoiding the session bean, you can eliminate remote calls, thus improving your performance. Also, check if the database & the db driver you are using supports sql caching.
    Regards,
    Raj.

  • Error in updating secondary stateful session bean

              Hi all,
              I have set up a cluster of 2 managed servers with WebLogic 6.1. I have a
              stateful session bean and several stateless session beans. the stateful
              session bean keeps user info and limited cached objects, all are
              serializable. it seems working fine, even after killing any one of the
              servers, as long as one is alive. a java application client creates a
              stateful session bean first, then calls stateless session beans with the
              remote interface of the stateful bean as a method parameter. No problem
              when stateful session bean is created. However, each stateless bean method
              generates the following error message if I turn the debug on (level 64). No
              exception stack traces, and all methods execute successfully.
              <Error> <EJB> <Failed to update the secondary copy of a stateful session
              bean from home:clientsession>
              I wonder what causes the error, and why it tries to update the stateful
              session bean. in all stateless session beans, only read into the stateful
              bean.
              Thank you,
              Fujin
              

    This has been fixed in WLS 6.1 SP2.
              jagdip Talla wrote:
              > Hi Fujin,
              > please let me know, if u were able to solve the problem..
              >
              > hi guys,
              > appreciate if you could give me some clues
              > how to solve this problem ?
              >
              > i hv 2 WLS instances in a cluster,
              > when one server instance is shut down, i keep getting these errors ?
              > is it normal ?
              > <Feb 19, 2002 2:57:53 PM SGT> <Error> <EJB> <Failed to update the secondary copy of a stateful session bean from home:ejb/xyzrel1_2/xxxxHome>
              >
              > appreciate if u can let me know, if u could solve it..?
              >
              > thanks n regads
              > jagdip
              Rajesh Mirchandani
              Developer Relations Engineer
              BEA Support
              

  • Toplink Optimistic Locking not working with Session Bean facade.

    I am working on Oracle JDeveloper v 10.1.2 and connecting to an Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit
    The application is based on J2EE architecture and the technology stack uses Struts for presentation/controller framework, Stateless Session EJBs as session facade for custom business services, Simple java classes for the business services, Toplink implementation of DAO layer, Domain objects are mapped to database tables using Toplink Workbench that ships with JDeveloper. The transaction is managed by the session bean and hence the toplink session is configured to use external transaction controller and a named datasource as follows.
    <session xsi:type="server-session">
    <name>DBSession</name>
    <server-platform xsi:type="oc4j-1012-platform"/>
    <event-listener-classes/>
    <logging xsi:type="toplink-log">
    <log-level>fine</log-level>
    <file-name>D:/ToplinkLog.log</file-name>
    </logging>
    <primary-project xsi:type="xml">META-INF/toplink-descriptor.xml</primary-project>
    <login xsi:type="database-login">
    <platform-class>oracle.toplink.platform.database.oracle.Oracle10Platform</platform-class>
    <external-connection-pooling>true</external-connection-pooling>
    <external-transaction-controller>true</external-transaction-controller>
    <sequencing>
    <default-sequence xsi:type="native-sequence">
    <name>Native</name>
    <preallocation-size>1</preallocation-size>
    </default-sequence>
    </sequencing>
    <datasource>jdbc/ORADS</datasource>
    </login>
    </session>
    We intend to use Optimistic Locking based on Timestamp-version locking through an audit field "last_modification_date" of type java.sql.Timestamp. The corresponding database field is also of type Timestamp(6). We are not storing the version in cache.
    The problem we are facing is as follows.. we have an edit screen from where user can edit values for a domain object which are then persisted using Toplink...we expect Toplink to check the database record version (modification_date timestamp) before it applies the update. In DAO implementation, we register the object in a unitOfWork, then set the modified values, however we leave the modification_date (version field) unedited. Now when the application is running, on edit, an exception is thrown by the Session bean before ending the transaction.
    com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: Error in transaction: java.lang.NullPointerException
         at TrackingMediator_StatelessSessionBeanWrapper2.editOverheadExpenditure(TrackingMediator_StatelessSessionBeanWrapper2.java:1597)
         at com.enbridge.dsm.web.action.TrackingPortfolioAction.editOverheadExpenditure(TrackingPortfolioAction.java:264)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java)
         at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:278)
         at com.enbridge.dsm.web.shared.BaseAction.execute(BaseAction.java:90)
         at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:465)
         at com.enbridge.dsm.web.shared.DSMPojoRequestProcessor.process(DSMPojoRequestProcessor.java:182)
         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1425)
         at com.sourcebeat.strutslive.common.SLActionServlet.process(SLActionServlet.java:44)
         at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
         at oracle.security.jazn.oc4j.JAZNFilter.doFilter(Unknown Source)
         at com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:16)
         at com.enbridge.dsm.web.shared.security.SecurityFilter.doFilter(SecurityFilter.java:142)
         at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:645)
         at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:322)
         at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
         at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
         at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
         at java.lang.Thread.run(Thread.java:534)
         Nested exception is:
    java.lang.NullPointerException
         at oracle.jdbc.driver.PhysicalConnection.commit(PhysicalConnection.java:1190)
         at com.evermind.sql.FilterConnection.commit(FilterConnection.java:209)
         at com.evermind.sql.DriverManagerXAConnection.commit(DriverManagerXAConnection.java:203)
         at com.evermind.server.TransactionEnlistment.commit(TransactionEnlistment.java:251)
         at com.evermind.server.ApplicationServerTransaction.singlePhaseCommit(ApplicationServerTransaction.java:745)
         at com.evermind.server.ApplicationServerTransaction.commit(ApplicationServerTransaction.java:690)
         at com.evermind.server.ApplicationServerTransaction.end(ApplicationServerTransaction.java:1035)
         at TrackingMediator_StatelessSessionBeanWrapper2.editOverheadExpenditure(TrackingMediator_StatelessSessionBeanWrapper2.java:1593)
         at com.enbridge.dsm.web.action.TrackingPortfolioAction.editOverheadExpenditure(TrackingPortfolioAction.java:264)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java)
         at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:278)
         at com.enbridge.dsm.web.shared.BaseAction.execute(BaseAction.java:90)
         at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:465)
         at com.enbridge.dsm.web.shared.DSMPojoRequestProcessor.process(DSMPojoRequestProcessor.java:182)
         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1425)
         at com.sourcebeat.strutslive.common.SLActionServlet.process(SLActionServlet.java:44)
         at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
         at oracle.security.jazn.oc4j.JAZNFilter.doFilter(Unknown Source)
         at com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:16)
         at com.enbridge.dsm.web.shared.security.SecurityFilter.doFilter(SecurityFilter.java:142)
         at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:645)
         at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:322)
         at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
         at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
         at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
         at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
         at java.lang.Thread.run(Thread.java:534)
    Note that the exception is thrown at the time when the session bean is about to commit the transaction. i.e. the DAO code did not throw any exception and was able to check the optimistic locking and submit the update transaction.
    I am not able to understand why is the the EJB throwing this weird error with Optimistic locking implementation. The application is working fine when the optimistic locking is disabled.
    I am facing another problem due to this problem... since the session bean throws this exception after exiting the bean implemented method, when trying to commit the transaction, I am not able to mark the session context to setRollbackOnly. Hence if I continue on to another transaction by navigating to another screen in the application, mysteriously the previous transaction gets committed!!... again... weird...

    I am using JDBC driver version 10.1.2.
    I saw this additional error message in JDeveloper console, which for some reason was not logged to my log4j log file... if it helps...
    06/09/22 18:32:10 Thr[thread 6]-TransactionEnlistment.TransactionEnlistment.Caught forgetandRollback XAException e null
    Here are the logs from my Toplink log file....
    [TopLink Info]: 2006.09.22 06:31:46.546--ServerSession(989)--Thread(Thread[HttpRequestHandler-86,5,main])--TopLink, version: Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)
    [TopLink Info]: 2006.09.22 06:31:46.578--ServerSession(989)--Thread(Thread[HttpRequestHandler-86,5,main])--Server: Oracle Application Server Containers for J2EE 10g (10.1.2.0.0)
    [TopLink Config]: 2006.09.22 06:31:46.593--ServerSession(989)--Connection(991)--Thread(Thread[HttpRequestHandler-86,5,main])--connecting(DatabaseLogin(
         platform=>Oracle10Platform
         user name=> ""
         connector=>JNDIConnector datasource name=>jdbc/ORADS
    [TopLink Config]: 2006.09.22 06:31:47.484--ServerSession(989)--Connection(1432)--Thread(Thread[HttpRequestHandler-86,5,main])--Connected: jdbc:oracle:thin:@10.210.16.37:1521:orabld
         User: APP_USR
         Database: Oracle Version: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
    With the Partitioning, OLAP and Data Mining options
         Driver: Oracle JDBC driver Version: 10.1.0.3.0
    [TopLink Config]: 2006.09.22 06:31:47.500--ServerSession(989)--Connection(1433)--Thread(Thread[HttpRequestHandler-86,5,main])--connecting(DatabaseLogin(
         platform=>Oracle10Platform
         user name=> ""
         connector=>JNDIConnector datasource name=>jdbc/ORADS
    [TopLink Config]: 2006.09.22 06:31:47.500--ServerSession(989)--Connection(1434)--Thread(Thread[HttpRequestHandler-86,5,main])--Connected: jdbc:oracle:thin:@10.210.16.37:1521:orabld
         User: APP_USR
         Database: Oracle Version: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
    With the Partitioning, OLAP and Data Mining options
         Driver: Oracle JDBC driver Version: 10.1.0.3.0
    [TopLink Info]: 2006.09.22 06:31:47.671--ServerSession(989)--Thread(Thread[HttpRequestHandler-86,5,main])--DBSession login successful
    [TopLink Fine]: 2006.09.22 06:31:47.703--ServerSession(989)--Connection(1554)--Thread(Thread[HttpRequestHandler-86,5,main])--select * from user_role ur, app_resource ar, role_resource rr where rr.APP_RESOURCE_ID = ar.APP_RESOURCE_ID and rr.USER_ROLE_ID = ur.USER_ROLE_ID
    [TopLink Fine]: 2006.09.22 06:31:49.937--ServerSession(989)--Connection(10245)--Thread(Thread[HttpRequestHandler-86,5,main])--SELECT * FROM PROGRAM_SUB_CAT
    [TopLink Fine]: 2006.09.22 06:31:50.015--ServerSession(989)--Connection(10332)--Thread(Thread[HttpRequestHandler-86,5,main])--SELECT PROGRAM_ID, CREATED_BY_USERID FROM (SELECT CREATED_BY_USERID, ROWNUM PROGRAM_ID FROM (SELECT DISTINCT(CREATED_BY_USERID) CREATED_BY_USERID, 1 AS PROGRAM_ID FROM PROGRAM))
    (I only see my application specific queries after this... no exceptions or debug logs)... as I said before.. the application gives exception in the session bean at the time of commit, and there's no exception raised from Toplink code in DAO...

  • NON-transactional session bean access entity bean

    We are currently profiling our product using Borland OptmizeIt tool, and we
    found some interesting issues. Due to our design, we have many session beans which
    are non transactional, and these session beans will access entity beans to do
    the reading operations, such as getWeight, getRate, since it's read only, there
    is no need to do transaction commit stuff which really takes time, this could
    be seen through the profile. I know weblogic support readonly entity bean, but
    it seems that it only has benefit on ejbLoad call, my test program shows that
    weblogic still creates local transaction even I specified it as transaction not
    supported, and Transaction.commit() will always be called in postInvoke(), from
    the profile, we got that for a single method call, such as getRate(), 80% time
    spent on postInvoke(), any suggestion on this? BTW, most of our entity beans are
    using Exclusive lock, that's the reason that we use non-transactional session
    bean to avoid dead lock problem.
    Thanks

    Slava,
    Thanks for the link, actually I read it before, and following is what I extracted
    it from the doc:
    <weblogic-doc>
    Do not set db-is-shared to "false" if you set the entity bean's concurrency
    strategy to the "Database" option. If you do, WebLogic Server will ignore the
    db-is-shared setting.
    </weblogic-doc>
    Thanks
    "Slava Imeshev" <[email protected]> wrote:
    Hi Jinsong,
    You may want to read this to get more detailed explanation
    on db-is-shared (cache-between-transactions for 7.0):
    http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1127563
    Let me know if you have any questions.
    Regards,
    Slava Imeshev
    "Jinsong HU" <[email protected]> wrote in message
    news:[email protected]...
    Thanks.
    But it's still not clear to me in db-is-shared setting, if I specifiedentity
    lock as database lock, I assumed db-is-shared is useless, because foreach
    new
    transaction, entity bean will reload data anyway. Correct me if I amwrong.
    Jinsong
    "Slava Imeshev" <[email protected]> wrote:
    Jinsong,
    See my answers inline.
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    Hi Slava,
    Thanks for your reply, actually, I agree with you, we need to
    review
    our db
    schema and seperate business logic to avoid db lock. I can not say,guys,
    we need
    to change this and that, since it's a big application and developedsince
    EJB1.0
    spec, I think they are afraid to do such a big change.Total rewrite is the worst thing that can happen to an app. The
    better aproach would be identifying the most critical piece and
    make a surgery on it.
    Following are questions in my mind:
    (1) I think there should be many companies using weblogic serverto
    develop
    large enterprise applications, I am just wondering what's the maintransaction/lock
    mechanism that is used? Transional session / database lock,
    db-is-shared
    entity
    I can't say for the whole community, as for my experience the standard
    usage patthern is session fasades calling Entity EJBs while having
    Required TX attribute plus plain transacted JDBC calls for bulk
    reads or inserts.
    is the dominant one? It seems that if you speficy database lock,
    the
    db-is-shared
    should be true, right?Basically it's not true. One will need db-is-shared only if thereare
    changes
    to the database done from outside of the app server.
    (2) For RO bean, if I specify read-idle-timeout to 0, it shouldonly
    load
    once at the first use time, right?I assume read-timeout-seconds was meant. That's right, but if
    an application constantly reads new RO data, RO beans will be
    constantly dropped from cache and new ones will be loaded.
    You may want to looks at server console to see if there's a lot
    of passivation for RO beans.
    (3) For clustering part, have anyone use it in real enterpriseapplication?
    My concern, since database lock is the only way to choose, how aboutthe
    affect
    of ejbLoad to performance, since most transactions are short live,if high
    volume
    transactions are in processing, I am just scared to death about
    the
    ejbLoad overhead.
    ejbLoad is a part of bean's lifecycle, how would you be scared ofit?
    If ejbLoads take too much time, it could be a good idea to profile
    used SQLs. Right index optimization can make huge difference.
    Also you may want cosider using CMP beans to let weblogic
    take care about load optimization.
    (4) If using Optimization lock, all the ejbStore need to do
    version
    check
    or timestamp check, right? How about this overhead?As for optimistic concurrency, it performs quite well as you can
    use lighter isolation levels.
    HTH,
    Slava Imeshev
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    We are using Exclusive Lock for entity bean, because of we do
    not
    want
    to
    load
    data in each new transaction. If we use Database lock, that means
    we
    dedicate
    data access calls to database, if database deadlock happens,
    it's
    hard
    to
    detect,
    while using Exclusive lock, we could detect this dead lock in
    container
    level.
    The problem is, using Exclusive concurrency mode you serialize
    access to data represented by the bean. This aproach has negative
    effect on ablity of application to process concurrent requests.As
    a
    result the app may have performance problems under load.
    Actually, at the beginnning, we did use database lock and usingtransactional
    The fact that you had database deadlocking issues tells that
    application logic / database schema may need some review.
    Normally to avoid deadlocking it's good to group database
    operations mixing in updattes and inserts into one place so
    that db locking sequence is not spreaded in time. Moving to
    forced serialized data access just hides design/implementation
    problems.
    session bean, but the database dead lock and frequent ejbLoad
    really
    kill
    us,
    so we decided to move to use Exclusive lock and to avoid dead
    lock,
    we
    change
    some session bean to non-transactional.Making session beans non-transactions makes container
    creating short-living transactions for each call to entity bean
    methods. It's a costly process and it puts additional load to
    both container and database.
    We could use ReadOnly lock for some entity beans, but since weblogicserver will
    always create local transaction for entity bean, and we found
    transaction
    commit
    is expensive, I am arguing why do we need create container leveltransaction for
    read only bean.First, read-only beans still need to load data. Also, you may seeRO
    beans
    contanly loading data if db-is-shared set to true. Other reason
    can
    be
    that
    RO semantics is not applicable the data presented by RO bean (forinstance,
    you have a reporting engine that constantly produces "RO" data,
    while
    application-consumer of that data retrieves only new data and neverasks
    for "old" data). RO beans are good when there is a relatively stable
    data
    accessed repeatedly for read only access.
    You may want to tell us more about your app, we may be of help.
    Regards,
    Slava Imeshev
    I will post the performance data, let's see how costful
    transaction.commit
    is.
    "Cameron Purdy" <[email protected]> wrote:
    We are currently profiling our product using Borland
    OptmizeIt
    tool,
    and we
    found some interesting issues. Due to our design, we have
    many
    session
    beans which
    are non transactional, and these session beans will access
    entity
    beans
    to
    do
    the reading operations, such as getWeight, getRate, since
    it's
    read
    only,
    there
    is no need to do transaction commit stuff which really takes
    time,
    this
    could
    be seen through the profile. I know weblogic support readonly
    entity
    bean,
    but
    it seems that it only has benefit on ejbLoad call, my test
    program
    shows
    that
    weblogic still creates local transaction even I specified
    it
    as
    transaction not
    supported, and Transaction.commit() will always be called
    in
    postInvoke(),
    from
    the profile, we got that for a single method call, such as
    getRate(),
    80%
    time
    spent on postInvoke(), any suggestion on this? BTW, most of
    our
    entity
    beans are
    using Exclusive lock, that's the reason that we use
    non-transactional
    session
    bean to avoid dead lock problem.I am worried that you have made some decisions based on an improper
    understand of what WebLogic is doing.
    First, you say "non transactional", but from your description
    you
    should
    have those marked as tx REQUIRED to avoid multiple transactions
    (since
    non-transactional just means that the database operation becomesits
    own
    little transaction).
    Second, you say you are using exclusive lock, which you shouldonly
    use
    if
    you are absolutely sure that you need it, (and note that it
    does
    not
    work in
    a cluster).
    Peace,
    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com/coherence.jsp
    Tangosol Coherence: Clustered Replicated Cache for Weblogic
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    >

  • HOWTO:Deploy BC4J as Session Bean in Weblogic

    This document describes Howto deploy a BC4J Appmodule as EJB Session Bean to Weblogic and
    test the appmodule through the BC4J tester.
    =>create a BC4J Application using Business Components Wizard.
    =>test it using BC4J tester
    =>make the Application Module Remotable [list]
    [*]Select Appmodule and right mouse on it to select the edit option
    [*]Select Remote tab
    [*]Select the check box for Remotable Application Module
    [*]Select EJB Session Bean and shuttle it from Available list to Selected list
    [*]Click on the finish button[list]
    => Do File| Save All and a Rebuild on the project
    => create the weblogic XML Deployment Descriptor[list]
    [*]Choose File|New
    [*]Select the web objects tab
    [*]Select XML and click ok
    [*]Rename the file as ejb-jar.xml using File|Rename
    [*]Save it in the JDEV_HOME/myclasses/META-INF directory.
    [*]Open the xml file by double clicking on it.
    [*]Paste the following into the file
    <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
    <ejb-jar>
    <enterprise-beans>
    <session>
    <ejb-name>wl.WlModule</ejb-name>
    <home>wl.common.ejb.WlModuleHome</home>
    <remote>wl.common.ejb.RemoteWlModule</remote>
    <ejb-class>wl.server.ejb.WlModuleServerEJB</ejb-class>
    <session-type>Stateful</session-type>
    <transaction-type>Bean</transaction-type>
    </session>
    </enterprise-beans>
    <assembly-descriptor>
    </assembly-descriptor>
    </ejb-jar>
    [*]Choose File|New
    [*]Select the web objects tab
    [*]Select XML and click ok
    [*]Rename the file as weblogic-ejb-jar.xml using File|Rename
    [*]Save it in the JDEV_HOME/myclasses/META-INF directory.
    [*]Open the xml file by double clicking on it.
    [*]Paste the following into the file
    <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN' 'http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd'>
    <weblogic-ejb-jar>
    <weblogic-enterprise-bean>
    <ejb-name>wl.WlModule</ejb-name>
    <caching-descriptor>
    <max-beans-in-free-pool>100</max-beans-in-free-pool>
    <max-beans-in-cache>100</max-beans-in-cache>
    <idle-timeout-seconds>60</idle-timeout-seconds>
    </caching-descriptor>
    <jndi-name>wl.WlModule</jndi-name>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>
    In this example "wl" is the package name and "WlModule" is the Appmodule name.[list]
    => generate the jar file for appmodule along with xml deployment descriptors[list]
    [*]from the command line in JDEV_HOME/myclasses directory run
    [*]jar cvf0 wlappmodule.jar wl META-INF[list]
    => edit the setenv.cmd file in WEBLOGIC_HOME directory[list]
    [*]set JAVA_HOME=f:\jdev32\java1.2
    [*]set JBOLIB=f:\jdev32\lib
    [*]set JDBC_CLASSES=f:\jdev32\jdbc\lib\oracle8.1.7\classes12.zip
    [*]set JBO_RUNTIME=%JBOLIB%\jboorasql.zip;%JDBC_CLASSES%;%JBOLIB%\jbodatum12.zip;%JBOLIB%\xmlparserv2.jar;%JBOLIB%\jbomt.zip;%JBOLIB%\jboejb.jar
    [*]add JBO_RUNTIME in the set CLASSPATH variable[list]
    => create a bc4j deploy batch file "Deploybc4j.cmd" in the WEB_LOGIC HOME
    which will generate the server side jar files
    @setlocal
    set JAVA=java
    set JAVAC=javac
    set BEAN_JAR=%1
    set EJB_TEMP=f:\jdev32\myclasses\wl
    set XMLPARSERV2=f:\jdev32\lib\xmlparserv2.jar;
    set JDBC_LIBS=f:\jdev32\jdbc\oracle8.1.7\lib\classes12.zip
    set JBO_EJB_RUNTIME=f:\jdev32\lib\jbomt.zip;f:\jdev32\lib\jboejb.jar;%XMLPARSERV2%;%JDBC_LIBS%
    set CLASSPATH=%CLASSPATH%;%JBO_EJB_RUNTIME%;%BEAN_JAR%;%EJB_TEMP%
    %JAVA% weblogic.ejbc -compiler javac f:\jdev32\myclasses\wlappmodule.jar f:\jdev32\myclasses\wlAppModuleGenerated.jar;f:\jdev32\lib\jbodomorcl.zip
    pushd %EJB_TEMP%
    @endlocal
    Note: substittue appropriate jar file and directory structure names
    => Run setenv.cmd
    => Run deploybc4j.cmd
    => Configure Weblogic server[list]
    If your weblogic server is residing on a different machine then
    [*]copy wlAppModuleGenerated.jar (generated jar file from deploybc4j.cmd)
    [*]Copy classes12.zip from JDEV_HOME/jdbc/lib/oracle8.1.7/ directory
    [*]Copy jbodomorcl.zip
    [*]jbodatum12.zip
    [*]xmlparserv2.jar
    [*]jbomt.zip
    [*]jboejb.jar from JDEV_HOME/lib directory
    [*]edit weblogic.properties file in WEBLOGIC_HOME directory
    [*]In the WEBLOGIC EJB DEMO PROPERTIES sectio
    [*]add weblogic.ejb.deploy=E:/weblogic/myserver/wlAppModuleGenerated.jar
    (generated jar file from deploybc4j.cmd file)
    [*]edit startweblogic.cmd file in WEBLOGIC_HOME directory
    [*]set POST_CLASSPATH=f:\jdev32\jdbc\oracle8.1.7\lib\classes12.zip;f:\jdev32\lib\jboorasql.zip;f:\jdev32\lib\jbodatum12.zip;f:\jdev32\lib\xmlparserv2.jar;f:\jdev32\lib\jbomt.zip;f:\jdev32 \lib\jboEJB.jar;f:\jdev32\lib\jbodomorcl.zip
    [*]add E:/weblogic/myserver/wlAppModuleGenerated.jar
    (generated jar file from deploybc4j.cmd file) in the weblogic_classpath setting[list]
    Note: modify the directory structure of jar files as apporpriate
    => Run the BC4J tester to test the deployed BC4J Appmodule as session bean to Weblogic[list]
    [*]Add a new library
    [*]Select the Project in which you developed the BC4J Appmodule
    [*]Project | Project Properties
    [*]select libraries tab
    [*]Click on Add
    [*]Click on New
    [*]Specify "JBO WL Client" in the NAME
    [*]Click on ... button for adding the jar files
    [*]Click on Add/Zip jar button to add the following files
    weblogicaux.jar
    jboremoteejb.zip
    jboremote.zip
    <Weblogic_home>/classes
    [*]Click on OK
    [*]Start the weblogic server
    [*]Bring the BC4J Tester by doing a right mouse on the appmodule and selecting Test option
    [*]In the Middle Tier Server Type Select "Weblogic"
    [*]Specify Host name and port # of weblogic server
    [*]Click on Connect[list]
    raghu
    null

    Although this explains how to then deploy to Weblogic on another server, it still presumes that it is installed on the same computer as JDev. I moved the weblogic.jar file over to the computer and fudged a few things to get it to work.
    Also, I am testing this with Weblogic 6.0, so some of the information does not work as prescribed. I edited the config.xml instead of the weblogic.properties file. I am trying to figure out where to put all of the *.jar and *.zip files that I copied over to the Solaris machine with Weblogic. Any suggestions?
    And one of the steps in the section to create the deploybc4j.cmd file is wrong. It says
    "%JAVA% weblogic.ejbc -compiler javac f:\jdev32\myclasses\wlappmodule.jar f:\jdev32\myclasses\wlAppModuleGenerated.jar;f:\jdev32\lib\jbodomorcl.zip"
    Which does not work. I took off the last part:
    "%JAVA% weblogic.ejbc -compiler javac f:\jdev32\myclasses\wlappmodule.jar f:\jdev32\myclasses\wlAppModuleGenerated.jar"
    and it worked. It was getting that whole last part and trying to create a directory with that name and failing.
    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by David Shanes ([email protected]):
    This seems to assume that JDev and Weblogic are installed on the same server (I refer to the section on setting the setenv.cmd file in the WEBLOGIC_HOME dir that includes the path to the JDev install.
    I have JDev installed on a Win 2k box and Weblogic installed on a Solaris. Any suggestions? I got all the way up to the setenv.cmd step fine.<HR></BLOCKQUOTE>
    null

  • Would RollBacks For Stateless Session Beans work In case of Stored Procedures or Triggers Written in Oracle PL/SQl

              We are writing a J2EE application and using Weblogic 5.1 on Unix machine. We are
              considering writing some Stored Procedures or Triggers on Oracle DBMS. Hence our
              Stateless Session Beans / Data Access Objects (DAOs) would be calling those stored
              procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These Data
              Access Objects are running under the umbrella of a Stateless Session Beans). We
              are using WebLogic's Connection Pooling.
              Our question is: Would we get reliable rollbacks from our stored procedures. I
              mean would the Transaction Management process of the EJB container work. Remember
              the SQL is written in the Database (Oracle in this case) in the form of Stored
              Procedures / Triggers through PL/SQL.
              Any ideas or tips would help.
              

              I would agree with Cameron Purdy. Be very cautious to use Oracle specific
              Triggers / Stored Procedures. Consider following, (apart from what he said):
              1. Unreliable behaviour of the Oracle JDBC drivers, specially 8.1.6 family..
              (You may visit the Oracle's web site and see the newsgroups for the JDBC drivers).
              This is enough of a reason to stop right there.
              However for interest sake you may consider following issues:
              2. By use of Oracle specific Triggers / SPs the application will not be portable.
              Vendor Lock In. Remember your choice for J2EE compliant Server (WebLogic in this
              case). The whole purpose would be defeated by going for this option.
              3. There are issues related to the extensibility of the application. I have
              my reservations and would hold my breath on two phase commit protocol transactions
              being reliable in this scenario.
              Have fun...
              Terry
              "Cameron Purdy" <[email protected]> wrote:
              >Yes, the work performed by the SPs and the triggers would be in the same
              >tx.
              >
              >What would NOT work is if the data has been read into WebLogic and then
              >it
              >gets affected by a trigger or SP on the RDBMS, the data in WebLogic is
              >not
              >automatically re-read within that same tx so you need to be careful.
              >
              >Peace,
              >
              >--
              >Cameron Purdy
              >Tangosol Inc.
              >Tangosol Coherence: Clustered Coherent Cache for J2EE
              >Information at http://www.tangosol.com/
              >
              >
              >"Ahmad" <[email protected]> wrote in message
              >news:[email protected]...
              >>
              >> We are writing a J2EE application and using Weblogic 5.1 on Unix machine.
              >We are
              >> considering writing some Stored Procedures or Triggers on Oracle DBMS.
              >Hence our
              >> Stateless Session Beans / Data Access Objects (DAOs) would be calling
              >those stored
              >> procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These
              >Data
              >> Access Objects are running under the umbrella of a Stateless Session
              >Beans). We
              >> are using WebLogic's Connection Pooling.
              >> Our question is: Would we get reliable rollbacks from our stored
              >procedures. I
              >> mean would the Transaction Management process of the EJB container
              >work.
              >Remember
              >> the SQL is written in the Database (Oracle in this case) in the form
              >of
              >Stored
              >> Procedures / Triggers through PL/SQL.
              >> Any ideas or tips would help.
              >
              >
              

  • Can we implement "Service Locator" in Stateless Session Bean??

    Hi,
    My enterprise application is using Stateless Session Bean. To increase the performace , I think of implementing "service Locator" pattern so as to cache the EJBHome objects in order to avoid looking up Home object every time. I want to know whether this will work out in case of stateless session bean??
    Thanks for ur help.

    Hi,
    The purpose of service locator is to abstract the lookup of the server side services like ejb and DSNs. It should be a normal java class but as such there is no such restriction. You can have a look at the service locator patter at the j2ee blue prints.
    /Ashwani

  • Database access from session bean

    Hello,
    I have a stateless session bean which performs some complex
    calculations, and also does some database access.
    For the database access the bean class has a datasource as
    follows:
    public class TestBean implements SessionBean {
    private DataSource ds_;
    public void ejbCreate() {
         getDataSources();
    private void getDataSources() {
         try {
         Context ictx = new InitialContext();
         ds_ = (DataSource)ictx.lookup("java:comp/env/jdbc/TestDB");
         } catch (Exception e) {
         e.printStackTrace();
         throw new EJBException(e);
    Now this class has a method (which is also in the remote interface)
    calculateSomething(). This method constructs a number of other
    objects that do the actual calculation, and one of these objects
    does the actual database access. How would another object be able to
    use the datasource that was constructed in the bean class?
    I could pass the datasource reference to that object, but that would
    break my encapsulation. This is because that object does not get
    created directly by the bean object, but rather the way the objects
    interact is something like A -> B -> C, where A is the TestBean, and
    C is the object that does the DB access. If I passed the datasource,
    I would need to make B aware of the datasource, which doesn't
    seem good design, because B doesn't do any database access.
    Alternatively I could do the lookup in class C, but that would
    degrade the performance, as an object C gets created and destroyed
    every time the calculateSomething() method is called.
    A third option I have thought of, is to add a public method to the
    bean that returns a connection. Whenever another object gets
    created, a reference to the bean object will be passed along. Then,
    if another object needs to do database access, it will call back
    the bean to get a connection. This seems just as bad (if not worse)
    than the first option.
    Does anyone have an elegant solution for this situation? What is
    the best practice of handling datasources when a bean class doesn't
    do the database access itself? In all the examples I've seen so far,
    all the functionality was in the session bean class, but again that
    doesn't seem good OO design, and would result in a single huge class.
    regards,
    Kostas

    Thanks again to both for the replies. Here are my responses:
    Yi Lin: Yes, I know that an entity bean would solve this problem, however it has been decided not to use entity beans so this is not my call (I think the reason entity beans are not allowed in this project is that they are considered risky: there are other applications that access the same database, so if the container caches entity bean data as you describe, then the users might get inconsistent results).
    Gerard: Actually object B is the one that has the business logic and C is a peer object that only does database access and no calculaitons. For example B can be Customer, and C CustomerDB. This is why object B does not have any knowledge of datasources or connections. So my design does not appear to be that bad!
    As far as the factory you propose is concerned, I cannot understand how this would solve my problem. In order to solve this situation the factory would need to be persistent, i.e. get created by the ejbCreate() method, and destroyed whenever the container decides to destroy the bean. There would be no point in object C creating the factory, as I would have the overhead of doing the JNDI lookup every time I create a C.
    So the question remains the same: how would I pass a reference to the factory from A to C without making B aware of it?

  • Best way to remove Stateful session beans

    Hi folks.
    I'm running Weblogic 6.1. I'm trying to find the best way of removing
    stateful session beans. I know to call EJBObject.remove() on the
    client side, but this will not always happen if the client crashes or
    times out. This is a java client application connection to weblogic,
    no servlets are involved.
    Is there a way to signal the appserver to remove all stateful session
    beans associated with a user when the User logs out? I would rather
    not remove them using a time out mechanism.
    thanks.
    rob.

    But in the documentation and also based on my experience I noticed that the
    timeout does not take effect till the max-beans-in-cache limit is reached.
    How do you handle that?
    "Thomas Christen" <[email protected]> wrote in message
    news:3e35795d$[email protected]..
    Hi,
    Is there a way to signal the appserver to remove all stateful session
    beans associated with a user when the User logs out? I would rather
    not remove them using a time out mechanism.Had the same problem and solved it the following way :
    - The client has thread polling its sessionbean at the server (every 30
    Sec.)
    - The session bean has a short timeout (2 Minutes)
    If the client fails, the timeout will catch it otherwise the client will
    gracefully call remove bevor exit.
    Regards
    Tomy

  • When to use ApplicationBean  and Session Bean dataproviders

    hi i am developing a small application, in which i have cached rowset and if i want to access the database i have to call the bean component so which one to call either application Bean or Session Bean component in some examples they used application bean and in some applications they used session bean. Please suggest me the right one and i have to access the database correctly. I am confused ,please help me out in solving this problem.
    Thanking You in Advance.

    The following excerpt is from http://developers.sun.com/prodtech/javatools/jscreator/learning/tutorials/2/scopes.html
    Before you create a bean property to store a value, you must decide what scope to put the property in. Because several users can access a web application at the same time, you want to use the smallest scope possible so that you don't waste valuable space. The following figure illustrates the duration of each type of scope.
    * Application scope lasts until the server stops the application. Values that you store in an application bean are available to every session and every request that uses the same application map.
    * Session scope begins when a user first accesses a page in the web application and ends when the session times out due to inactivity, or when the web application invalidates the session, such as, for example, by calling session.invalidate().
    * Request scope begins when the user submits the page and ends when the response is fully rendered, whatever page that is.

  • In-memory-replace for stateful session bean

    When I add "<replication-type>InMemory</replication-type>" at the
              weblogic-ejb-jar.xml file,
              the client can't call this stateful session bean and happen exception.
              If I delete "<replication-type>InMemory</replication-type>" at the
              weblogic-ejb-jar.xml, the client can call this ejb.
              How does the In-memory-replac set?
              Is there any limitations about using the In-memory-replace?
              The weblogic-ejb-jar.xml and the exception are list.
              The weblogic-ejb-jar.xml:
              <?xml version="1.0"?>
              <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0
              EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>test_stateful</ejb-name>
              <stateful-session-descriptor>
              <stateful-session-clustering>
              <home-is-clusterable>True</home-is-clusterable>
              <home-load-algorithm>round-robin</home-load-algorithm>
              <home-call-router-class-name>beanRouter</home-call-router-class-name>
              <replication-type>InMemory</replication-type>
              </stateful-session-clustering>
              </stateful-session-descriptor>
              <jndi-name>test_stateful</jndi-name>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              The exception:
              java.rmi.RemoteException: EJB Exception: ; nested exception is:
              java.lang.ClassCastException:
              weblogic.rmi.internal.BasicRequestDispatcher
              java.lang.ClassCastException: weblogic.rmi.internal.BasicRequestDispatcher
              <<no stack trace available>>
              

    This is a Work as designed in my opinion
    with NRU ,the container work with an eager remove algorithm, this as stated need pressure at the cache to push the container to remove the beans from the cache ,hence there will no passivation unless the max-beans-in-cache is reached, hence you can try reducing the max-beans-in-cache and see how the caching behaves , if It does not help ,chnage the Algorithm of caching or open a Service Request for us , we can look at this closely
    Regards
    Anis

  • Local Stateful Session Bean State Failover Cluster

              Hi,
              How are you doing? I have poured through the previous postings and still am unclear
              on the following: If we have a stateful session bean that is local is the state
              replicated in a cluster if we are using in-memory replication?
              What controls when the state is replicated? Transactions?
              What happens if the methods are not transacted? Is the state replication at the
              method level?
              Thank you so much,
              -Bart Simpson
              

    Hi Bart,
              I'm a bit unclear on it too. It's been asked before, but no definite answer
              has been provided.
              Peace,
              Cameron Purdy
              Tangosol, Inc.
              http://www.tangosol.com/coherence.jsp
              Tangosol Coherence: Clustered Replicated Cache for Weblogic
              "Bart Simpson" <[email protected]> wrote in message
              news:[email protected]..
              >
              > Hi,
              >
              > How are you doing? I have poured through the previous postings and still
              am unclear
              > on the following: If we have a stateful session bean that is local is the
              state
              > replicated in a cluster if we are using in-memory replication?
              >
              > What controls when the state is replicated? Transactions?
              >
              > What happens if the methods are not transacted? Is the state replication
              at the
              > method level?
              >
              > Thank you so much,
              > -Bart Simpson
              

  • HttpSession vs. Stateful Session Bean ---- when State Session is large

    I hope most of the people come across with this issue where to put the state
    for the internet/intranet based applications when they are using
    servlet/jsps calling session beans. Weblogic 4.5.1 does support httpsession
    in-memory replication for the servlets but the stateful session beans are
    not replicated in clustered environment. Plus with stateful bean u get
    activation/passivation overhead too. So one tempts to use stateless session
    beans and store state in httpsession?
    Then what is the upper limit for the session state one can put in
    HttpSession with the weblogic? Is there any way to configure it?
    One way to overcome the httpsession size limitation is to use database for
    storing state and just store some unique Ids for the session info in
    httpSession. But then there will be overhead for database connection?(jdbc
    connection pool can provide some help here). So what is the recommended way
    for doing this provided few thousand concurrent clients with session size
    say exceeding 4kb per client?
    Thanks
    Usmani

    There are no special setting in sun-ejb-jar.xml regarding cache settings. The default settings from server.xml are used:
        <jdbc-connection-pool steady-pool-size="8" max-pool-size="32" max-wait-time-in-millis="60000" pool-resize-quantity="2" idle-timeout-in-seconds="300" is-isolation-level-guaranteed="false" is-connection-validation-required="false" connection-validation-method="auto-commit" fail-all-connections="false" datasource-classname="oracle.jdbc.pool.OracleDataSource" name="ebs">
          <property value="jdbc:oracle:thin:@myebsdbsserver:1521:ebsdevdb" name="url"/>
          <property value="ebs" name="user"/>
          <property value="ebs" name="password"/>
        </jdbc-connection-pool>
      <ejb-container steady-pool-size="32" pool-resize-quantity="16" max-pool-size="64" cache-resize-quantity="32" max-cache-size="512" pool-idle-timeout-in-seconds="600" cache-idle-timeout-in-seconds="600" removal-timeout-in-seconds="5400" victim-selection-policy="nru" commit-option="B" monitoring-enabled="true">
         </ejb-container>The Session Bean uses Container Managed Transaction. Is it possible in this case, that the bean isn't 'idle enough' in order to set into passivated?

Maybe you are looking for

  • Circling Objects

    Hello, Is there a way to circle objects, such as a person with a ring or circle in Final Cut Express HD?

  • What's going on with this log entry?

    kernel[0]: BUG in process suhelperd[199]: over-released legacy external boost assertions (1 total, 1 external, 0 legacy-external) And more to the point, how can I correct it. This is repeated many times in the sys log.

  • What does unexpected error -8003 mean?

    When I try to empty the trash I get the following message: The operation can't be completed because an unexpected error occurred (error code -8003). Help Jim

  • PSE 11 - Photomerge: No alignment possible for panorama even with equal focus width

    Plötzlich habe ich ein Problem mit Photomerge: Fotos lassen sich nicht mehr zu einem Panorama zusammenfügen, obwohl alle mit gleichem Cameraprogramm und gleicher Brennweite erzeugt wurden. (PhSE 11). "Suddenly" I got a problem with Photomerge in PhSE

  • IPhoto 11 - Inconsistencies in your library

    Running OSX 10.7.2 and latest version of iPhoto. Upgraded all software as the library needed to be upgraded to work with this version after several failed attempts to upgrade the library I upgraded all software (OS & iPhoto). I then get the message "