StateFul SessionBean Passivation

I am running a EJB application in weblogic, using StateFul SessionBean.Suppose say,
the maximum number of clients at a time is 100.(And assume that this is the maximum no of beans taht are created).Now 2 more clients 101,102 are coming.This time the 1st,2nd client are idle, so that their beans are passivated.Now What will happen,
1.Whether the container will create 2 more beans for the 101,102 client
or
2.the Clients shouold wait until, any 2 of the previously created clients going to logout
or
3.I read in EdRoman Book, the following,Excerpt
if a SF bean is passivated for a particular client.And the client again came the same bean is not necessarily to serve for that client.Any bean can activate and work for the client, from the point where the original bean is left.
If this is the case.
then the container will activate the 2 beans and give it to them(101, 102 ).And now the original client (that is 1, 2 clients ) agin they are invoking business method .Now they(1,2nd) should wait for any other 2 clients beans for passivation.

Thanks for the suggestion Barry, but since we are using a client application
that creates the SSB directly, there's no servlet or intermediate
server-side bean to implement HttpSessionBindingListener. I'll check, but
I'm pretty sure the SSB can't implement it itself. Still, it's food for
thought...
Cheers,
Dave
"Barry Munro" <[email protected]> wrote in message
news:[email protected]..
On 03 Dec 2001, Dave Lorde wrote:
We would like to be able to force passivation or removal of stateful
session beans whose idle timeout has expired or where the client has
disconnected. Any ideas?To remove them when your user session expires you could use
javax.servlet.http.HttpSessionBindingListener so that you are informedwhen
the user's session is unbound from the session. Then you could call the
remove method of your stateful session bean which calls the ejbRemove
method on the SSB.
Barry

Similar Messages

  • BlazeDS and Stateful SessionBeans?

    Hi,
    is it possible to Access Stateful SessionBeans with BlazeDS?
    And what Application Server do you use, i heard that there might be problems by using GlassFish v2.1.
    Regards,
    Florian

    Hi,
    is it possible to Access Stateful SessionBeans with BlazeDS?
    And what Application Server do you use, i heard that there might be problems by using GlassFish v2.1.
    Regards,
    Florian

  • Avoid java.rmi.NoSuchObjectException: Stateful SessionBean has timed-out

    I have a "java.rmi.NoSuchObjectException: Stateful SessionBean has timed-out" error when I call a statefull session bean after timeout,
    I would like to check if a bean was removed before calling a method (and so generate a rmi.NoSuchObjectException).

    No you wouldn't. It could time out between the check and the call. The correct way to do it is the way you are already doing it: attempt the operation and deal with the failure.

  • Stateful SessionBean - force passivation or removal

    Is there any way of forcing passivation or removal of stateful session beans
    once their idle-timeout-seconds has been exceeded? Alternatively, can a
    stateful session bean get notification of a client disconnection?
    We have a special requirement for stateful session beans to hold a
    transaction open over multiple calls (using bean-managed transactions),
    which means keeping a connection open. Therefore, we have a connection as a
    (transient) member variable, and when the bean is passivated or removed, the
    transaction is rolled back and the connection is closed... OK, so far no
    problem. However, during this transaction, the session bean maintains a lock
    on part of the database preventing others from interfering with the updates.
    A problem arises if the client crashes or is disconnected somehow, as the
    session bean still remains active, only becoming eligible for passivation or
    removal after it's idle timeout has expired.Unfortunately, even when the
    idle timeout expires, the session bean is not passivated or removed, even if
    the max number of beans in the cache is exceeded... In fact, there is no
    guarantee it will ever be passivated or removed unless the server runs short
    of memory.
    We would like to be able to force passivation or removal of stateful session
    beans whose idle timeout has expired or where the client has disconnected.
    Any ideas?
    Dave

    Thanks for the suggestion Barry, but since we are using a client application
    that creates the SSB directly, there's no servlet or intermediate
    server-side bean to implement HttpSessionBindingListener. I'll check, but
    I'm pretty sure the SSB can't implement it itself. Still, it's food for
    thought...
    Cheers,
    Dave
    "Barry Munro" <[email protected]> wrote in message
    news:[email protected]..
    On 03 Dec 2001, Dave Lorde wrote:
    We would like to be able to force passivation or removal of stateful
    session beans whose idle timeout has expired or where the client has
    disconnected. Any ideas?To remove them when your user session expires you could use
    javax.servlet.http.HttpSessionBindingListener so that you are informedwhen
    the user's session is unbound from the session. Then you could call the
    remove method of your stateful session bean which calls the ejbRemove
    method on the SSB.
    Barry

  • EJB3 Stateful Sessionbean how to implement multi business interfaces?

    Hi All,
    I met up some issue, can't make the session bean implement 2 business interfaces? Please kindly throw me some light! thanks
    Business sessionbean
    @Stateful
    @ConversationScoped
    @Named
    @Local( { IWizard.class, IRegisterWizard.class })
    public class RegisterWizard extends WizardBean {
    @Local
    public interface IWizard extends Serializable {
            public String back();
            public boolean hasBack();
            public boolean hasNext();
            public String next();
            public String abort();
    @Local
    public interface IRegisterWizard{
            public String submit();
    }error message of glassfish3 below:
    Caused by: java.lang.IllegalArgumentException: Not enough type information to resolve ejb for  ejb name class wizard.RegisterWizard
            at org.glassfish.weld.services.EjbServicesImpl.resolveEjb(EjbServicesImpl.java:121)
            at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:422)
            at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:76)
            at org.jboss.weld.bean.SessionBean.create(SessionBean.java:298)
            ... 53 more

    There does appear to be a bug in the handling of the bean with multiple business interfaces. I filed an issue for it :
    https://glassfish.dev.java.net/issues/show_bug.cgi?id=11826. The inheritance is a separate issue. Are you getting the same error or a different one after applying @LocalBean.

  • Stateful SessionBean Problem

    hi to all i have a problem with sessionBean i need that stateful type but when run my aplication in first intance runs ok but when a call another method throws a exception:
    javax.ejb.NoSuchEJBException: Bean has been deleted.
    i already modify the weblogic-ejb-jar.xml to determine that bean is a Stateful type but not working
    my tecnologies:
    model:
    ejb 3.0
    viewController:
    adf11g rich elements
    jspx
    hope can help me
    Regards Everardo.
    Edited by: Everardo Dominguez on 5/07/2010 08:59 AM

    Hello, I am new to adf and EJB/EclipseLink, so I have a question
    May be my question is not the same as a topic starter had, But I have quite close issue with Stateful session beans and related bean life exceptions.
    I have app with Model and ViewController parts (as created using default Jdev master for Fusion Web Applications). In Model I have a Stateful bean running some businesses logic. On View I have one of the Statful ejb bean methods exposed through data control as adf form with input field and button action like "#{bindings.fireMdxQuery.execute}", so in some cases this method can throw exception, and Stateful bean will be removed.
    Method signature for local bean interface looks like:
    public void fireMdxQuery(String query) throws ConnectionException, OperationException;
    For first call example I could achieve first - normal exception stacktrace, and then on second bean call -      
    java.lang.reflect.InvocationTargetException
    Bean has been deleted.
    Caused by: javax.ejb.NoSuchEJBException: Bean has been deleted.
    Could you please provide,what is the best way to determine, that statefull bean has been removed, to have ability to redirect user to some special place or running some businesses logic in such case? Am I expected to use managed bean, use code like
    OperationBinding method = getBindings().getOperationBinding("exposed_stateful_ejb_method_name");
    method.getParamsMap().put("param", value);
    method.execute();
    List<Exception> list = method.getErrors();
    and every time checking for javax.ejb.NoSuchEJBException?
    Thank you.

  • What happens if you don't define '@Remove' method for Stateful SessionBean?

    Hi,
    I'm new to ejb3.
    I've noticed that the spec doesn't force you to define a "@Remove" method on a stateful Session bean... which seemed a bit weird/dangerous to me...
    Would anyone please happen to know:
    1. Is there a special treatment for Staeful SB's that don't have "@Remove"? Like, for examle, will the container destroy the session automatically at some point (after each remove invocation ? After a fixed timeout ? etc).
    2. And what if the programmer defined '@Remove' but neglected to call it from the client ? Are there different rules ? Session timeout ?
    Thanks a lot !

    There are always ways in which the container can decide to remove a Stateful Session Bean(SFSB) that are completely independent of whether a client explicitly calls a remove method. The container can choose to remove a SFSB because it has timed out. The actual time out is typically configurable, much like HttpSession timeout. The container can also remove a SFSB due to a system exception generated from one of its methods.
    @Remove methods merely expose an application-specific way to force the removal of a SFSB. They are not required to be defined and even if defined are not required to be invoked.
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • How do i get back my stateful session bean after it has been passivated

    hi ,
    How do i get back my stateful session bean after it has been passivated by container.
    i'm confused that is it possible or not .......give me answer
    i've one stateful sessionbean which i'm accessing throgh my normal java client . now what i'm doing is when i first time call a method it is running ......then i'm shutting down the server jboss .......it is calling my ejbPassivate() method ... at this particular time client program doesn't do anything.....
    now after i restart my server i'm again calling back that business method with that last object reference.......it gives me the exception given below.....
    java.rmi.NoSuchObjectException: no such object in table
    java.rmi.NoSuchObjectException: no such object in table
         at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source)
         at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)
         at sun.rmi.server.UnicastRef.invoke(Unknown Source)
         at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
         at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:118)
         at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
         at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
         at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
         at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
         at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
         at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
         at $Proxy1.makeNewAcc(Unknown Source)
         at client.GanJavaClient.main(GanJavaClient.java:46)so pls tell me that is it possible to get back that session besn or not

    Stateful session beans are not persisted across restart of the EJB server instance(s) hosting them. You can't treat a Session bean as one would an entity bean.
    Chuck

  • How to instantiate more than one of a sessionbean

    Hi,
    I'm looking for a way to instantiate a stateful sessionbean ten times at the same time.
    for(int i=0; i<= 10; i++){
    MySessionBean bean = MySessionBeanHome.create();
    bean.doSomethingWith(i);
    That doesn't work, because it'll waiting for the return of doSomethingWith(). But I have to start the Bean without waiting for the return...
    Any ideas??
    Stefan

    Hello, you can use Threads in there, now you may decide if you want to use the Thread in the server or client.
    For exemple, if you want to create a Thread on the Server the doSomethingWith() creates the Thread and returns.
    If you want create the Thread on the client you must create a Thread object on the client who will create the Object and execute the method.
    Hope this helps.

  • Deploying Stateful Session Bean

    hi!
    I've got a problem when deploying a Stateful SessionBean. It worked well for about 1 week. I changed a little thing in the BeanClass, and afterwards only got deployment errors. taking back the changes had no effect.
    Furthermor the Error seems to be nonsens, because I deploy from a EAR, and this ear contains all Files of the Stateful SessionBean. The container seems to have problems to read the jar file within the ear file ...???
    cu
    ed
    C:\jdev\jdk\jre\bin\javaw.exe -jar C:\jdev\j2ee\home\admin.jar ormi://localhost/ admin **** -deploy -file D:\DATEN\CVS\revdb\Implementierung\Java\ejbsession\EJBSession.ear -deploymentName revdb_ejb
    Fatal Error: Error loading class 'at.gv.brz.revdb.ejb.ejbsession.session.impl.EJBSessionBean': java.lang.NoClassDefFoundError: at.gv.brz.revdb.ejb.ejbsession.session.impl.EJBSessionBean
    Auto-unpacking C:\jdev\j2ee\home\applications\EJBSession.ear... done.
    Copying default deployment descriptor from archive at C:\jdev\j2ee\home\applications\EJBSession/META-INF/orion-application.xml to deployment directory C:\jdev\j2ee\home\application-deployments\revdb_ejb...
    Auto-deploying revdb_ejb (New server version detected)...
    java.lang.InstantiationException: Error loading class 'at.gv.brz.revdb.ejb.ejbsession.session.impl.EJBSessionBean': java.lang.NoClassDefFoundError: at.gv.brz.revdb.ejb.ejbsession.session.impl.EJBSessionBean
         void com.evermind.server.ejb.deployment.BeanDescriptor.initialize(com.evermind.server.ejb.deployment.EJBDeploymentContext)
              BeanDescriptor.java:294
         void com.evermind.server.ejb.deployment.ExposableBeanDescriptor.initialize(com.evermind.server.ejb.deployment.EJBDeploymentContext)
              ExposableBeanDescriptor.java:131
         void com.evermind.server.ejb.deployment.SessionBeanDescriptor.initialize(com.evermind.server.ejb.deployment.EJBDeploymentContext)
              SessionBeanDescriptor.java:360
         void com.evermind.server.ejb.deployment.EJBPackage.initialize(com.evermind.server.ejb.EJBContainer, com.evermind.server.administration.ApplicationInstallation)
              EJBPackage.java:650
         com.evermind.server.ejb.deployment.EJBPackage com.evermind.server.ejb.EJBPackageDeployment.getPackage()
              EJBPackageDeployment.java:673
         java.util.Map com.evermind.server.administration.ServerApplicationInstallation.finish(java.util.Map)
              ServerApplicationInstallation.java:517
         java.lang.Object java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[])
              native code
         void com.evermind.server.rmi.RMICallHandler.run(java.lang.Thread)
              RMICallHandler.java:119
         void com.evermind.server.rmi.RMICallHandler.run()
              RMICallHandler.java:48
         void EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run()
              PooledExecutor.java:803
         void java.lang.Thread.run()
              Thread.java:484

    hi Jeff!
    I tried some different tasks.
    1.) removing all deployments (incl. app in server.xml) -> still error
    2.) manually deploying to a "virgin" container -> still error
    3.) manually deploying an old and stable version (runs on a colleages oc4j instance) -> still error
    4.) copying app-dirs + config-dir from a colleage (its his running instance) -> STILL ERROR!!
    5.) copying his whole J2EE-dir -> deployment works!
    It looks like, that one of my deployments (out of Jdeveloper with admin.jar) has kicked my container and the container kept in tilt mode (to use a little flippermachine slang ;o)
    Besides from joking, I still think it's a serious thing. I'm now going to install a whole fresh instance of Jdeveloper and OC4J. Hopefully afterwards I won't have these probs again.
    If someone @ Oracle wants to take a look at these instance (like bugsearching) dont hesitate to contact me (I'll keep both version of the OC4J, running and tilt one).
    cu
    ed

  • Stateful session bean deploying

    Hello,
              I try to deploy stateful SessionBean with WL 6.0.
              Content of my 'weblogic-ejb-jar.xml' file is:
              <?xml version="1.0"?>
              <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0
              EJB//EN' 'http://www.bea.com/servers/wls60/ejb20/dtd/weblogic-ejb-jar.dtd'>
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>HashtableSessionBean</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>
              <jndi-name>HashtableSessionBean</jndi-name>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              But I still recive error like bellow:
              ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003> <myserver>
              <Application Manager Thread> <> <> <160002> <Error deploying EJB Component :
              HashtableSessionBean>
              weblogic.ejb20.EJBDeploymentException: Exception in EJB Deployment; nested
              exception is:
              javax.naming.NamingException [Root exception is java.rmi.MarshalException:
              failed to marshal public abstract void
              weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
              ava.util.Hashtable) throws
              javax.naming.NamingException,java.rmi.RemoteException; nested exception is:
               java.rmi.server.ExportException: Failed to invoke contructor for
              RuntimeDescriptor: class weblogic.rmi.internal.BasicRuntimeDescriptor;
              nested exception is:
               java.lang.reflect.InvocationTargetException]
              javax.naming.NamingException. Root exception is java.rmi.MarshalException:
              failed to marshal public abstract void
              weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
              ava.util.Hashtable) throws
              javax.naming.NamingException,java.rmi.RemoteException; nested exception is:
              java.rmi.server.ExportException: Failed to invoke contructor for
              RuntimeDescriptor: class weblogic.rmi.internal.BasicRuntimeDescriptor;
              nested exception is:
              java.lang.reflect.InvocationTargetException
              java.rmi.server.ExportException: Failed to invoke contructor for
              RuntimeDescriptor: class weblogic.rmi.internal.BasicRuntimeDescriptor;
              nested exception is:
              java.lang.reflect.InvocationTargetException
              java.lang.reflect.InvocationTargetException: java.lang.NoClassDefFoundError:
              weblogic/common/managedobject/JavaRemoteManageable
              at java.lang.ClassLoader.defineClass0(Native Method)
              at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
              at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
              at
              weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLo
              ader.java:304)
              at
              weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.
              java:155)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
              at weblogic.rmi.utils.Utilities.classForName(Utilities.java:209)
              at weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:88)
              at weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:141)
              at
              weblogic.rmi.internal.BasicRuntimeDescriptor.<init>(BasicRuntimeDescriptor.j
              ava:59)
              at java.lang.reflect.Constructor.newInstance(Native Method)
              at
              weblogic.rmi.internal.DescriptorManager.resolveClass(DescriptorManager.java:
              81)
              at
              weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
              :39)
              at
              weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
              :30)
              at
              weblogic.rmi.internal.OIDManager.getRequestDispatcher(OIDManager.java:279)
              at weblogic.rmi.internal.OIDManager.getReplacement(OIDManager.java:268)
              at weblogic.rmi.internal.OIDManager.replaceObject(OIDManager.java:96)
              at
              weblogic.common.internal.WLObjectOutputStreamBase2.replaceObject(WLObjectOut
              putStreamBase2.java:47)
              at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:323)
              at
              weblogic.rmi.internal.CBVOutputStream.writeObjectInternal(CBVOutputStream.ja
              va:220)
              at
              weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:213)
              at
              weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:190)
              at weblogic.rmi.internal.ObjectIO.writeObject(ObjectIO.java:19)
              at
              weblogic.rmi.internal.BasicRemoteRef.marshalArgs(BasicRemoteRef.java:121)
              at
              weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
              :246)
              at
              weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
              :225)
              at
              weblogic.jndi.internal.ServerNamingNode_WLStub.rebind(ServerNamingNode_WLStu
              b.java:502)
              at weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:123)
              at weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:117)
              at
              weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.deploy(ClientDrivenBeanInfo
              Impl.java:483)
              at weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java:1105)
              at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:908)
              at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:31)
              at weblogic.j2ee.Application.addComponent(Application.java:126)
              at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115)
              at
              weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
              arget.java:283)
              at
              weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
              arget.java:109)
              at java.lang.reflect.Method.invoke(Native Method)
              at
              weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
              .java:562)
              at
              weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
              48)
              at
              weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
              nImpl.java:285)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              at
              weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(Confi
              gurationMBeanImpl.java:409)
              at
              weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
              nImpl.java:287)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              at
              weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
              .java:866)
              at
              weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
              .java:853)
              at
              weblogic.management.internal.DynamicMBeanImpl.add(DynamicMBeanImpl.java:838)
              at
              weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
              .java:566)
              at
              weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
              48)
              at
              weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
              nImpl.java:285)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:437)
              at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:178)
              at $Proxy8.addTarget(Unknown Source)
              at
              weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(ApplicationM
              anager.java:486)
              at
              weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
              ionManager.java:557)
              at
              weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
              ionManager.java:504)
              at
              weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
              .java:428)
              at
              weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
              .java:380)
              at
              weblogic.management.mbeans.custom.ApplicationManager.update(ApplicationManag
              er.java:152)
              at
              weblogic.management.mbeans.custom.ApplicationManager$ApplicationPoller.run(A
              pplicationManager.java:643)
              ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003> <myserver>
              <Application Manager Thread> <> <> <160001> <Error deploying application
              HashtableSessionBean: Could not deploy: 'HashtableSessionBean.jar'
              Possible reasons include:
              1. The bean or an interface class has been modified but
              the deployment descriptor has not been updated
              2. The database mappings in the deployment descriptor do not
              match the database definition
              3. The jar file is not a valid jar file
              4. The jar file does not contain a valid bean>
              Robert
              

    Hello,
              <stateful-session-clustering>
              <replication-type>InMemory</replication-type>
              </stateful-session-clustering>
              Statement above belongs to 'weblogic-ejb-jar.xml' and it is right in my
              opinion.
              I have another one statement describing SessionBean which deploy it as
              stateful bean (it is 'ejb-jar.xml' file):
              <?xml version="1.0"?>
              <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
              JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
              <ejb-jar>
              <enterprise-beans>
              <session>
              <ejb-name>HashtableSessionBean</ejb-name>
              <home>com.usermgmt.sessionbeans.hashtable.HashtableSessionHome</home>
              <remote>com.usermgmt.sessionbeans.hashtable.HashtableSession</remote>
              <ejb-class>com.usermgmt.sessionbeans.hashtable.HashtableSessionBean</ejb-cla
              ss>
              <session-type>Stateful</session-type>
              <transaction-type>Container</transaction-type>
              </session>
              </enterprise-beans>
              <assembly-descriptor></assembly-descriptor>
              </ejb-jar>
              I think that everything should go right, but SessionBean is not replicated.
              Where is the problem?
              Robert
              Uzytkownik "Prasad Peddada" <[email protected]> napisal w wiadomosci
              news:[email protected]...
              > Its not stateful session descriptor from your xml file instead it is
              > stateful-session-clustering according to the docs.
              >
              > -- Prasad
              >
              > ps: For ejb questions you will get better answers if you post to ejb
              newsgroup.
              >
              >
              > <stateful-session-clustering>
              >
              >
              > ...
              >
              >
              > <replication-type>InMemory</replication-type>
              >
              >
              > </stateful-session-clustering>
              >
              >
              > Robert Zaczynski wrote:
              >
              > > Thanks for help. I resolved this problem but my Stateful SessionBean
              doesn't
              > > replicate.
              > > Have I to use any special statement or settings???
              > >
              > > Robert
              > >
              > > Uzytkownik "Prasad Peddada" <[email protected]> napisal w
              wiadomosci
              > > news:[email protected]...
              > > > Did you modify the weblogic specific deployment descriptor xml file
              after
              > > > running ejbc. If so, you should run ejbc again and then jar it up
              again
              > > and
              > > > trying deploying and your problem should go away.
              > > >
              > > >
              > > > Cheers
              > > >
              > > > -- Prasad
              > > >
              > > > "Robert Zaczyñski" wrote:
              > > >
              > > > > Hello,
              > > > >
              > > > > I try to deploy stateful SessionBean with WL 6.0.
              > > > >
              > > > > Content of my 'weblogic-ejb-jar.xml' file is:
              > > > >
              > > > > <?xml version="1.0"?>
              > > > >
              > > > > <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD
              WebLogic
              > > 6.0.0
              > > > > EJB//EN'
              > > 'http://www.bea.com/servers/wls60/ejb20/dtd/weblogic-ejb-jar.dtd'>
              > > > > <weblogic-ejb-jar>
              > > > > <weblogic-enterprise-bean>
              > > > > <ejb-name>HashtableSessionBean</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>
              > > > >
              > > > > <jndi-name>HashtableSessionBean</jndi-name>
              > > > >
              > > > > </weblogic-enterprise-bean>
              > > > > </weblogic-ejb-jar>
              > > > >
              > > > > But I still recive error like bellow:
              > > > >
              > > > > ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003>
              > > <myserver>
              > > > > <Application Manager Thread> <> <> <160002> <Error deploying EJB
              > > Component :
              > > > > HashtableSessionBean>
              > > > > weblogic.ejb20.EJBDeploymentException: Exception in EJB Deployment;
              > > nested
              > > > > exception is:
              > > > > javax.naming.NamingException [Root exception is
              > > java.rmi.MarshalException:
              > > > > failed to marshal public abstract void
              > > > >
              > >
              weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
              > > > > ava.util.Hashtable) throws
              > > > > javax.naming.NamingException,java.rmi.RemoteException; nested
              exception
              > > is:
              > > > >  java.rmi.server.ExportException: Failed to invoke contructor for
              > > > > RuntimeDescriptor: class
              weblogic.rmi.internal.BasicRuntimeDescriptor;
              > > > > nested exception is:
              > > > >  java.lang.reflect.InvocationTargetException]
              > > > > javax.naming.NamingException. Root exception is
              > > java.rmi.MarshalException:
              > > > > failed to marshal public abstract void
              > > > >
              > >
              weblogic.jndi.internal.NamingNode.rebind(java.lang.String,java.lang.Object,j
              > > > > ava.util.Hashtable) throws
              > > > > javax.naming.NamingException,java.rmi.RemoteException; nested
              exception
              > > is:
              > > > > java.rmi.server.ExportException: Failed to invoke contructor for
              > > > > RuntimeDescriptor: class
              weblogic.rmi.internal.BasicRuntimeDescriptor;
              > > > > nested exception is:
              > > > > java.lang.reflect.InvocationTargetException
              > > > > java.rmi.server.ExportException: Failed to invoke contructor for
              > > > > RuntimeDescriptor: class
              weblogic.rmi.internal.BasicRuntimeDescriptor;
              > > > > nested exception is:
              > > > > java.lang.reflect.InvocationTargetException
              > > > > java.lang.reflect.InvocationTargetException:
              > > java.lang.NoClassDefFoundError:
              > > > > weblogic/common/managedobject/JavaRemoteManageable
              > > > > at java.lang.ClassLoader.defineClass0(Native Method)
              > > > > at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
              > > > > at
              > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
              > > > > at
              > > > >
              > >
              weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLo
              > > > > ader.java:304)
              > > > > at
              > > > >
              > >
              weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.
              > > > > java:155)
              > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
              > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
              > > > > at weblogic.rmi.utils.Utilities.classForName(Utilities.java:209)
              > > > > at
              > > weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:88)
              > > > > at
              > > weblogic.rmi.internal.BasicDescriptor.<init>(BasicDescriptor.java:141)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.BasicRuntimeDescriptor.<init>(BasicRuntimeDescriptor.j
              > > > > ava:59)
              > > > > at java.lang.reflect.Constructor.newInstance(Native Method)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.DescriptorManager.resolveClass(DescriptorManager.java:
              > > > > 81)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
              > > > > :39)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.DescriptorManager.getDescriptor(DescriptorManager.java
              > > > > :30)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.OIDManager.getRequestDispatcher(OIDManager.java:279)
              > > > > at
              weblogic.rmi.internal.OIDManager.getReplacement(OIDManager.java:268)
              > > > > at
              weblogic.rmi.internal.OIDManager.replaceObject(OIDManager.java:96)
              > > > > at
              > > > >
              > >
              weblogic.common.internal.WLObjectOutputStreamBase2.replaceObject(WLObjectOut
              > > > > putStreamBase2.java:47)
              > > > > at
              java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:323)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.CBVOutputStream.writeObjectInternal(CBVOutputStream.ja
              > > > > va:220)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:213)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:190)
              > > > > at weblogic.rmi.internal.ObjectIO.writeObject(ObjectIO.java:19)
              > > > > at
              > > > >
              > >
              weblogic.rmi.internal.BasicRemoteRef.marshalArgs(BasicRemoteRef.java:121)
              > > > > at
              > > > >
              > >
              weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
              > > > > :246)
              > > > > at
              > > > >
              > >
              weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
              > > > > :225)
              > > > > at
              > > > >
              > >
              weblogic.jndi.internal.ServerNamingNode_WLStub.rebind(ServerNamingNode_WLStu
              > > > > b.java:502)
              > > > > at
              weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:123)
              > > > > at
              weblogic.jndi.internal.WLContextImpl.rebind(WLContextImpl.java:117)
              > > > > at
              > > > >
              > >
              weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.deploy(ClientDrivenBeanInfo
              > > > > Impl.java:483)
              > > > > at
              > > weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java:1105)
              > > > > at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:908)
              > > > > at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:31)
              > > > > at weblogic.j2ee.Application.addComponent(Application.java:126)
              > > > > at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:115)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
              > > > > arget.java:283)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentT
              > > > > arget.java:109)
              > > > > at java.lang.reflect.Method.invoke(Native Method)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
              > > > > .java:562)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
              > > > > 48)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
              > > > > nImpl.java:285)
              > > > > at
              > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              > > > > at
              > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(Confi
              > > > > gurationMBeanImpl.java:409)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
              > > > > nImpl.java:287)
              > > > > at
              > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              > > > > at
              > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
              > > > > .java:866)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.DynamicMBeanImpl.addDeployment(DynamicMBeanImpl
              > > > > .java:853)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.DynamicMBeanImpl.add(DynamicMBeanImpl.java:838)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl
              > > > > .java:566)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:5
              > > > > 48)
              > > > > at
              > > > >
              > >
              weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBea
              > > > > nImpl.java:285)
              > > > > at
              > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
              > > > > at
              com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1
              > > 523)
              > > > > at
              weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:437)
              > > > > at
              weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:178)
              > > > > at $Proxy8.addTarget(Unknown Source)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.ApplicationManager.autoDeploy(ApplicationM
              > > > > anager.java:486)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
              > > > > ionManager.java:557)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.ApplicationManager.addApplication(Applicat
              > > > > ionManager.java:504)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
              > > > > .java:428)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.ApplicationManager.poll(ApplicationManager
              > > > > .java:380)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.ApplicationManager.update(ApplicationManag
              > > > > er.java:152)
              > > > > at
              > > > >
              > >
              weblogic.management.mbeans.custom.ApplicationManager$ApplicationPoller.run(A
              > > > > pplicationManager.java:643)
              > > > > ####<2001-03-28 18:15:15 GMT+02:00> <Error> <J2EE> <clikra003>
              > > <myserver>
              > > > > <Application Manager Thread> <> <> <160001> <Error deploying
              application
              > > > > HashtableSessionBean: Could not deploy: 'HashtableSessionBean.jar'
              > > > > Possible reasons include:
              > > > > 1. The bean or an interface class has been modified but
              > > > > the deployment descriptor has not been updated
              > > > > 2. The database mappings in the deployment descriptor do not
              > > > > match the database definition
              > > > > 3. The jar file is not a valid jar file
              > > > > 4. The jar file does not contain a valid bean>
              > > > >
              > > > > Robert
              > > >
              > > > --
              > > > Cheers
              > > >
              > > > - Prasad
              > > >
              > > >
              >
              > --
              > Cheers
              >
              > - Prasad
              >
              >
              

  • Unitofwork in a stateful architecture

    Hi there,
    we're designing the particulars of how we'll use Toplink domainobject instances and UnitOfWork in our OC4J-Spring Webflow-JSF architecture that does not use the Transfer Object pattern but directly references domain object instances from JSF pages (facelets).
    In particular there's Re: TopLink vs Hibernate... revisited... again :) in the forum on using a UnitOfWork in a stateful architecture.
    For a fictional "change User" ( find user, select user, submit changed user for persistency) use case we see 3 alternatives:
    1. directly refer to UnitOfWork registered instances from JSF pages, UnitOfWork per page request.
    This model does not fit our requirements: it hands all control of how to do persistency to the presentation layer without any the need for interaction with some kind of backend service. How to handle Toplink persistency will be dispersed all over the presentation layer.
    2. make a copy of the user object (UnitOfWork.copyObject(Object domainObject, ObjectCopyingPolicy ocp) before mutating starts. Merge the mutated object back in the UoW at commit (UnitOfWork.mergeCloneWithReferences(Object domainObject). We are concerned that this encurs quite a heavy CPU/time performance penalty. Also there are some nitty gritty problems with non-privately owned referenced objects. And we'll lose the advantages of Toplink lazy-loading of referenced objects.
    3. use a UnitOfWork that survives page requests, directly refer to UnitOfWork registered instances from JSF pages. A UnitOfWork registered domainobject is handed to the presentation layer before mutating starts. A few page requests later the mutated UoW domain object instance is handed to a backend service that commits the UnitOfWork. The statefulness of this architecture is not a huge problem since we have server affinity anyway.
    Option 3 seems very efficient in performance and very well structured.
    It presents a problem though: a stateful architecture can maintain the UnitOfWork (indirectly) in the HttpSession or in a Stateful Sessionbean. Either way there's the chance of the instances getting swapped out to disk and resurrected. Is that supported? What's the recommended way of doing a stateful UnitOfWork architecture? What design was Doug Clark refering to? The documentation explicitly states that Toplink Sessions do not survice swapping out...
    Advice very much appreciated.
    Added HTML page breaks
    Message was edited by:
    Joost de Vries

    Oh, and as an extra complication: at the moment we're using Container Managed JTA Transactions ( two-phase commit) to commit RDBMS and JMS results.
    I'm not sure wether, using UoWs that survive page requests, using CMT is viable/helpful anymore...

  • Bean Passivation

    Does anybody out there know how to turn off Stateful Bean passivation ? Any
    help would be greatly appreciated.
    Thanks
    -Vivek

    Have you investigated the settings about "beans in cache" etc.?
    Also, make sure you ejbRemove session beans when you are done with them.
    There's nothing worse than passivating stuff that no one even wants ;-)
    Cameron Purdy
    "Vivek Arya" <[email protected]> wrote in message
    news:[email protected]..
    Does anybody out there know how to turn off Stateful Bean passivation ?Any
    help would be greatly appreciated.
    Thanks
    -Vivek

  • Stateful Bean replication

    Hi,
              Is this possible to deploy some Stateful SessionBean on few different WL
              instances in cluster in such way that content of each bean will be the same
              in every time???
              I mean that, if anybody will update Stateful SessionBean on first instatnce
              of WL, replication will make the same copy of bean on each WL instances and
              hance the user who will connect to second instance of WL will get the same
              content of bean like in first instance.
              If it is possible, are there any special recommends to accomplish it?
              Best regards,
              Robert
              

    Our replication uses a primary-secondary scheme where all requests are always
              directed to the primary copy unless the server on which it is residing fails...
              "Robert Zaczyñski" wrote:
              > Hi,
              >
              > Is this possible to deploy some Stateful SessionBean on few different WL
              > instances in cluster in such way that content of each bean will be the same
              > in every time???
              >
              > I mean that, if anybody will update Stateful SessionBean on first instatnce
              > of WL, replication will make the same copy of bean on each WL instances and
              > hance the user who will connect to second instance of WL will get the same
              > content of bean like in first instance.
              >
              > If it is possible, are there any special recommends to accomplish it?
              >
              > Best regards,
              > Robert
              

  • RE: design patterns involving EJBs and JDO

    Is the idea that you specify in some config file (xml?) the methods of
    your session bean, whether its stateful or stateless, the default bean
    transaction semantics, etc, then say "go" and it generates the home and
    remote interfaces and the skeletal session bean class?
    -----Original Message-----
    From: Eric Lindauer [mailto:[email protected]]
    Sent: Monday, June 25, 2001 8:26 AM
    To: JDO-ListServ
    Subject: Re: design patterns involving EJBs and JDO
    I don't think it's publicly available yet, I used to work there and was
    helping out a little with testing. I'll tell you in advance, it really
    works well. Much like the JDO implementation, the process of turning
    things into SesisonBeans is very transparent to the developer. I guess
    TT is going to make it available in another week or two, as time
    permits.
    ----- Original Message -----
    From: Matthew <mailto:[email protected]> Adams
    To: '[email protected]' <mailto:'[email protected]'>
    Sent: Monday, June 25, 2001 11:18 AM
    Subject: RE: design patterns involving EJBs and JDO
    IMHO, JDO replaces entity beans, but you'll have to decide for yourself.
    My recommendation would be to use session beans exclusively.
    Where do you get TechTrader's "SessionBean Creator"? What are its
    features? How do you use it?
    -----Original Message-----
    From: Eric Lindauer [mailto:[email protected]]
    Sent: Monday, June 25, 2001 8:12 AM
    To: JDO-ListServ
    Subject: design patterns involving EJBs and JDO
    Hi,
    I was just wondering, if you are using JDO for persistence, does it
    matter whether you wrap your objects with proxy EntityBeans or
    SessionBeans? I am currently demoing TechTrader's SessionBean creator,
    which makes means that for me creating SessionBeans is much easier than
    creating EntityBeans. I am currently using stateful SessionBeans to
    wrap the JDO objects, simply dropping them when the bean is passivated
    and refinding them ( they'll already be in the cache ) when the bean is
    activated.
    My main advantage in doing it this way is SessionBeans are so much
    easier to create. Do you see any problems looming, or any other
    advantages to this decision?
    Thanks in advance.
    Eric

    I don't think it's publicly available yet, I used to work there and was
    helping out a little with testing. I'll tell you in advance, it really
    works well. Much like the JDO implementation, the process of turning
    things into SesisonBeans is very transparent to the developer. I guess
    TT is going to make it available in another week or two, as time
    permits.
    ----- Original Message -----_
    From: Matthew <mailto:[email protected]> Adams_
    To: '[email protected]' <mailto:'[email protected]'>
    Sent: Monday, June 25, 2001 11:18 AM
    Subject: RE: design patterns involving EJBs and JDO
    IMHO, JDO replaces entity beans, but you'll have to decide for yourself.
    My recommendation would be to use session beans exclusively.
    Where do you get TechTrader's "SessionBean Creator"? What are its
    features? How do you use it?
    -----Original Message-----
    From: Eric Lindauer [mailto:[email protected]]
    Sent: Monday, June 25, 2001 8:12 AM
    To: JDO-ListServ
    Subject: design patterns involving EJBs and JDO
    Hi,
    I was just wondering, if you are using JDO for persistence, does it
    matter whether you wrap your objects with proxy EntityBeans or
    SessionBeans? I am currently demoing TechTrader's SessionBean creator,
    which makes means that for me creating SessionBeans is much easier than
    creating EntityBeans. I am currently using stateful SessionBeans to
    wrap the JDO objects, simply dropping them when the bean is passivated
    and refinding them ( they'll already be in the cache ) when the bean is
    activated._
    My main advantage in doing it this way is SessionBeans are so much
    easier to create. Do you see any problems looming, or any other
    advantages to this decision?
    Thanks in advance.
    Eric_

Maybe you are looking for

  • Windows 8.1

    Windows 8.1 is a mess.  It was released with so many issues it's not even funny.  I hope the upcoming update fixes some of these issues. The message boards are filled with people having problems connecting with other network pcs and printers. First t

  • Upgrading question regarding software to download for bo xi r2 to bo xi 3.1

    We are going from BO XI R2 Enterprise to BO XI 3.1 Enterprise.  I checked out the downloads section for BOX XI 3.1 and found these instances for downloads: BOE XI 3.1 (SERVER/CLIENT TOOLS) WIN (under installs) BOE XI3.1(SRVR/CLNT TOOLS) Patch WIN (un

  • Trying to use iCloud email on my pc - do I need to buy Outlook Express?

    I have an iPad and iPhone, but have kept my PC.  Converting to iCloud for my mail.  Do I need to buy Outlook Express to use iCloud email on my PC?

  • New Authorization objects When Adding New tcodes

    Hi Guys I have two Identical R3 Productiosn Systems One is Called Prd and the Othe RPP. When Going into Pfcg on PRD and adding A tocde I.e Mi02. It  already has mi01 and mi03.the authorization tab chnages from green to Yellow,.When Going into The Aut

  • Before I buy...I would like to know more about X-Fi

    Well?I been thinking of buying the Sound Blaster X-Fi Elite Pro instead of using my onboard sound. But I started to read on other fourms and product reviews and its about half split between on using a digital optical connection. I have these speakers