The pooled JMS session is enlisted in another transaction error

I have an MDB with pool size 2 deployed in weblogic 9.2.3(linux). I see the following error in server logs.
<May 27, 2009 7:32:26 AM CDT> <Error> <EJB> <BEA-010079> <An error occurred while attempting to receive a message from JMS for processing by a message-driven bean: javax.jms.JMSException: [J2EE:160054]The pooled JMS session is enlisted in another transaction and may not be used elsewhere
The exception is : javax.jms.JMSException: [J2EE:160054]The pooled JMS session is enlisted in another transaction and may not be used elsewhere
     at weblogic.deployment.jms.JMSExceptions.getJMSException(JMSExceptions.java:22)
     at weblogic.deployment.jms.WrappedTransactionalSession.enlistInTransaction(WrappedTransactionalSession.java:196)
     at weblogic.deployment.jms.WrappedMessageConsumer.receive(WrappedMessageConsumer.java:198)
     at weblogic.ejb.container.internal.JMSMessagePoller.processOneMessage(JMSMessagePoller.java:297)
     at weblogic.ejb.container.internal.JMSMessagePoller.pollContinuously(JMSMessagePoller.java:394)
     at weblogic.ejb.container.internal.JMSMessagePoller.pollForParent(JMSMessagePoller.java:517)
     at weblogic.ejb.container.internal.JMSMessagePoller.run(JMSMessagePoller.java:533)
     at java.lang.Thread.run(Thread.java:595)
>
any idea why this error is coming??

Looks it is like a bug, you can ask patch for from support.

Similar Messages

Using the same instance of a BADI in another transaction

Hello Everyone,
I have a SAP standard transaction which has an authorization BADI implemented. I developed another report which is similar to the before mentioned SAP report with a different transaction. The same BADI is called in the custom report also, because of a common function module (which has this BADI call). So, that means, the same instance of BADI is being called in the custom report also. The authorizations to display the data for both the transactions should be same.
Should I specifically call this BADI again in custom report or will all the authorizations be linked to the new transaction as well?
Thank you all in advance.
Rushi

The BADI call is nothing but a call to specific methods in the customer BADI implementation. So it should work from wherever it is called, even from customer programs copied from standard SAP code where the original call is made.
But I wonder why do you need to make a copy of SAP code.

Delete the stored archive sessions form SAP filesystem

Hello,
Can any one explain How to delete the stored archive sessions form SAP filesystem. any transaction to delete the session from physical path.
-thanks
Ramana

Not Sure , check this
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/402fae48-0601-0010-3088-85c46a236f50&overridelayout=true
Re: Maintenance in the /usr/sap file system
Edited by: Harsh Bhalla on Nov 28, 2009 10:10 AM

Enlisting a JMS session as part of a distributed tx in SFSB

Consider the following method in a SFSB (Seam 2.1.2, JBoss 4.2 AS, EJB 3.0, JPA 1.0, Hibernate as persistence provider). I am trying to enlist the JMS session as part of the distributed tx and testing this using both local-tx-datasource and xa-datasource (JBoss specific datasources). Apparently the JMS session is not joining the distributed tx because everything is working fine using local-tx-datasource, which it should not. I'm guessing that there are two separate tx's that are happening here instead of one distributed tx. Also, note the following:
//topicSession = conn.createTopicSession(false, TopicSession.AUTO_ACKNOWLEDGE);
topicSession = conn.createTopicSession(true, TopicSession.AUTO_ACKNOWLEDGE);     The first param in the createTopicSession() method marks it as transacted, which may be used to commit all or none of multiple JMS messages in a tx (e.g. publishing multiple topics to a message queue and guaranteeing atomicity). But I was thinking that would make JTA enlist it in the distributed tx and apparently it does not.
As per section 13.2.2 of JSR220-core:
"Behind the scenes, the EJB server enlists the session on the connection to the JMS provider
and the database connections as part of the transaction. When the transaction commits, the EJB
server and the messaging and database systems perform a two-phase commit protocol to ensure atomic
updates across all the three resources."
Somebody please explain what/how the transactional semantics are in this case when enlisting a db resource mgr and a JMS session resource mgr in a distributed tx (with or w/o Seam). thx.
SFSB:
@Name("startConversation")
@AutoCreate
@Install(true)
@Stateful
public class TestStartConversation implements TestStartConversationLocal{
@Logger
private Log log;
@In
private EntityManager em;
@In
private EntityManager em2;
private transient TopicPublisher topicPublisher;
private transient TopicSession topicSession;
private transient TopicConnection conn;
private transient Topic topic;
public void startup(){
log.info("in startup()");
List<Hotel> list = em.createQuery("from Hotel").getResultList();
log.info("list.size() = "+list.size());
Hotel hotel = null;
if (list != null && list.size() > 0) {
hotel = list.get(0);
hotel.setAddress("arbi's house1");
try{
InitialContext iniCtx = new InitialContext();
Object tmp = iniCtx.lookup("ConnectionFactory");
TopicConnectionFactory tcf = (TopicConnectionFactory) tmp;
conn = tcf.createTopicConnection();
topic = (Topic) iniCtx.lookup("topic/chatroomTopic");
//topicSession = conn.createTopicSession(false, TopicSession.AUTO_ACKNOWLEDGE);
topicSession = conn.createTopicSession(true, TopicSession.AUTO_ACKNOWLEDGE);
topicPublisher = topicSession.createPublisher(topic);
topicPublisher.publish( topicSession.createObjectMessage(new ChatroomEvent("connect", "arbime")) );
topicSession.commit();
catch(Exception e){
//noop
finally {
try {
topicSession.close();
conn.close();
catch(Exception e) {
//noop
}MDB:
@MessageDriven(activationConfig={
@ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Topic"),
@ActivationConfigProperty(propertyName="destination", propertyValue="topic/chatroomTopic")
@Name("logger")
public class LoggerBean implements MessageListener
@Logger Log log;
public void onMessage(Message msg)
try
ChatroomEvent event = (ChatroomEvent) ( (ObjectMessage) msg ).getObject();
log.info( "#0: #1", event.getUser(), event.getData()==null ? event.getAction() : event.getData() );
catch (JMSException jmse)
throw new RuntimeException(jmse);
}

I am using the following code now with the same results. It works w/o enlistment exception which is not what I'm expecting. So apparently there's no distributed tx? How can I check to see if there is a distributed tx and what resources (if any) have been enlisted?
private transient TopicPublisher topicPublisher;
     private transient XATopicSession topicSession;
     private transient XATopicConnection conn;
     private transient Topic topic;
     /******************************* begin methods *******************************/
     @TransactionAttribute(TransactionAttributeType.REQUIRED)
     public void startup(){
          log.info("in startup()");
          List<Hotel> list = em.createQuery("from Hotel").getResultList();
          log.info("list.size() = "+list.size());
          try{
               InitialContext iniCtx = new InitialContext();
               XATopicConnectionFactory tcf = (XATopicConnectionFactory) iniCtx.lookup("XAConnectionFactory");
              conn = tcf.createXATopicConnection();
              topic = (Topic) iniCtx.lookup("topic/chatroomTopic");
              topicSession = conn.createXATopicSession();
              topicPublisher = topicSession.getTopicSession().createPublisher(topic);
              topicPublisher.publish( topicSession.createObjectMessage(new ChatroomEvent("connect", "arbime")) );
          catch(Exception e){
               //noop
          finally {
               try {
                    topicSession.close();
                    conn.close();
               catch(Exception e) {
                    //noop
     }

[Deployer:149164] The domain edit lock is owned by another session

Hi,
I am a tertiary student currently doing a Jsp Application using Jdeveloper 11.1.1.3.0 . I am trying to run my application on the integrated weblogic server to test out my application but i keep getting deployment failure. The Error is:[Deployer:149164] The domain edit lock is owned by another session in exclusive mode - hence this deployment operation cannot proceed. May i know how do i solve this problem? Thanks alot.

Hi, I tried the way you told me but i am running my application on a integrated weblogic server provided by Jdeveloper and stated below are my error being shown to me when i deploy my application.
<May 21, 2010 3:18:59 PM SGT> <Warning> <Deployer> <BEA-149124> <Failures were detected while initiating deploy task for application 'Ipp_Project'. Error is: '[Deployer:149164]The domain edit lock is owned by another session in exclusive mode - hence this deployment operation cannot proceed.'>
[03:18:59 PM] #### Deployment incomplete. ####
[03:18:59 PM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)
#### Cannot run application Ipp_Project due to error deploying to IntegratedWebLogicServer.
[Application Ipp_Project stopped and undeployed from Server Instance IntegratedWebLogicServer]
I cannot find my admin console for the integrated weblogic server. Thanks.

Non-durable subscribers persists after the end of their JMS session

Hi all,
I'm using OAQ as my JMS Provider.
I have created code for publishing and recieving messages to/from topics. Messaging works fine, but I have one problem:
All my non-durable subscribers persists after the end of their JMS session. I always perform unsubscribe operation in code and then closing session and connection.
When I subscribe to topic, there's one more line in DB table ( etc. NAME: TSUB_1_24E6DB98A2EB7712E040A8C, TYPE: 65). I have expected that subscribers will be deleted after performing unsubscribe operation, but they don't...
Can you help me with this problem? Thanks for any answer.
Best Regards,
Juraj

Have you found a solution to this yet - because I face the same problem

Connect the current portal session to another user

We have to do application management for portal users. Often it's necessary to have the same view as the customer. So administrators need a portlet for specifying the user credentials and connecting the current portal session to this user. It's not possible to ask every user for his password.Has anybody created such a portlet?Is it possible to do this? Can I use the EDK or do I need the plumtreeserver - DLL? Which class do I need? Thanks for any help

Thank you - It works! Now I have an IPTSession-Object for the given user. But how can I set this to the current portal instance? I get only new sessions but I didn't find any way to change the current session.

Concurrent access to JMS session in servlet

          We have a servlet that accepts a request from a browser,
          retrieves info from the request, places it in a JMS message and
          then sends the msg to a JMS Queue. We create all the JMS
          objects (connection, session, etc.) at init time (all these
          objects have class scope). There is only one session and I was
          wondering because servlets are multithreaded, while a request is
          being handled for one client, if there is a context switch in
          the middle of that client's send in order to handle another
          client's request, two different threads will be accessing the
          same session concurrently. I know the spec advises against
          this. Am I thining too much on this one????? All I have to do
          is synchronize the send call however I was just wondering if it
          was truely necessary.
          How are other people doing this out there?
          Let me know,
          Mark


Hi Mark,
          You are definitely not thinking too much on this one! Multi-threading
          session access is unsafe and is definitely against spec. Either
          synchronize
          access, or, if performance is an issue, make sure each simultaneous
          sender has its
          own session.
          The WebLogic JMS Performance white paper on dev2dev.bea.com
          contains an example of a producer pool that looks like it should map
          well to your use case.
          Tom, BEA
          Mark Drifdon wrote:
          > We have a servlet that accepts a request from a browser,
          > retrieves info from the request, places it in a JMS message and
          > then sends the msg to a JMS Queue. We create all the JMS
          > objects (connection, session, etc.) at init time (all these
          > objects have class scope). There is only one session and I was
          > wondering because servlets are multithreaded, while a request is
          > being handled for one client, if there is a context switch in
          > the middle of that client's send in order to handle another
          > client's request, two different threads will be accessing the
          > same session concurrently. I know the spec advises against
          > this. Am I thining too much on this one????? All I have to do
          > is synchronize the send call however I was just wondering if it
          > was truely necessary.
          > How are other people doing this out there?
          >
          > Let me know,
          > Mark

JMS session is not closed even after calling close()

Hi All,
I am using JMS to receive and publish topics for a process,in my java code i
am creating new JMS Session on demand(ie., whenever a new topic is
received) after processing the topic i am closing the session with close(),but
still the session is not closed.In a period of time more sessions are created
and FD leaks occurs which stops the process functionality.
Later i moved the on demand session code to a static block, its working fine
and no FD leak occurs.
Is this a known behavior or any java bug is there to point this issue,please
help me regarding this.
Thanks,
Ants Balajei

You should try avoid creating sessions on demand but cache/pool them...
http://activemq.apache.org/how-do-i-use-jms-efficiently.html
James
http://www.iona.com/
Open Source the Enterprise Way

Unable to create a transacted JMS Session

          We have some code that worked perfectly under wls7.0 and earlier, but refuses to
          work under wls8.1. In our situation, we are unable to create a JMS Session with
          internal transactions.
          The result of the following code
          System.out.println("transacted_=" + transacted_);
          tsession=tcon.createTopicSession(transacted_, Session.AUTO_ACKNOWLEDGE);
          System.out.println("session.getTransacted()=" + tsession.getTransacted());
          is the following
          transacted_=true
          session.getTransacted()=false
          We have tried using xa true and false; but commonly use false.
          //from config.xml
          <JMSConnectionFactory JNDIName="corej2ee.jms.JMSConnectionFactory"
          Name="CoreJMSConnectionFactory" Targets="myserver"/>
          thanks,
          jim


An alternative is to modify the servlet code to use global (user)
          transactions instead of local (transacted session)
          transactions - the performance will likely be the same in your case -
          or may actually improve due to the activation of the pooling code.
          jim stafford wrote:
          > You were correct about us using the resource-ref. The documentation seemed to indicate
          > that our servlet code should have worked as initially developed, however the new
          > changes work
          >
          > //replace resource-ref lookup with env-entry to allow transacted JMS
          > //sessions. This is new with wls8.1
          > //tconFactory = (TopicConnectionFactory)
          > // ctx.lookup("java:comp/env/jms/topicFactory");
          > String factoryName =
          > (String)ctx.lookup("java:comp/env/jms/myConnectionFactory");
          > System.out.println("using global jndi name:" + factoryName);
          > tconFactory = (TopicConnectionFactory)
          > ctx.lookup(factoryName);
          > tcon = tconFactory.createTopicConnection();
          >
          > System.out.println("transacted_=" + transacted_);
          > tsession=tcon.createTopicSession(transacted_, Session.AUTO_ACKNOWLEDGE);
          > System.out.println("session.getTransacted()=" + tsession.getTransacted());
          >
          > --- output
          > Looking up topic connection factory
          > using global jndi name:corej2ee.jms.JMSConnectionFactory
          > transacted_=true
          > session.getTransacted()=true
          >
          > Tom Barnes <[email protected]> wrote:
          >
          >>Hi Jim,
          >>
          >>My first thought is that the app is running
          >>on the WL server and that the app is using EJB "resource
          >>references" to indirectly access its JMS resources.
          >>Stricter J2EE compliance in 8.1 causes JMS resources
          >>accessed via resource references to ignore the transacted flag.
          >>
          >>See "J2EE Compliance" under:
          >>http://edocs.bea.com/wls/docs81/jms/j2ee_components.html#1033768
          >>
          >>The work-around is to directly specify the JNDI name
          >>of the CF in the app directly instead of looking it up
          >>via a resource reference.
          >>
          >>Please let me know if this helps.
          >>
          >>Tom
          >>
          >>jim stafford wrote:
          >>
          >>
          >>>We have some code that worked perfectly under wls7.0 and earlier, but
          >>
          >>refuses to
          >>
          >>>work under wls8.1. In our situation, we are unable to create a JMS
          >>
          >>Session with
          >>
          >>>internal transactions.
          >>>
          >>>The result of the following code
          >>>
          >>>System.out.println("transacted_=" + transacted_);
          >>>tsession=tcon.createTopicSession(transacted_, Session.AUTO_ACKNOWLEDGE);
          >>>System.out.println("session.getTransacted()=" + tsession.getTransacted());
          >>>
          >>>is the following
          >>>
          >>>transacted_=true
          >>>session.getTransacted()=false
          >>>
          >>>We have tried using xa true and false; but commonly use false.
          >>>
          >>>//from config.xml
          >>><JMSConnectionFactory JNDIName="corej2ee.jms.JMSConnectionFactory"
          >>> Name="CoreJMSConnectionFactory" Targets="myserver"/>
          >>>
          >>>thanks,
          >>>jim
          >>
          >

Timeout before connections are put back in the pool ?

Hi,
I am running a test with a single client : the test client send a requests,
wait for the response and when it gets it send another request and so on.
Looking at the connection pool, I can see that up to 8 DB connections
(connection high column in the WL console) have been used during the test
and I'm wondering why.
Our code has the following logic :
- get connection from pool
- execute query
- release connection (done in a finally block)
We're 100% sure the connections get put back in the pool after each
request. Is it possible that it would take some time before the connection
is put back in the pool which would explain why we use more than 1
connection ?
Thanks
-Vincent

"Priscilla Fung" <[email protected]> wrote in message
news:[email protected]...
Hi,
All these attributes are for internal JDBC XA connection pool usages only.
Their main purpose is to work around bugs of various vendor's JDBC XA
drivers. Therefore, by default, it should be turned off. Also, they are
only applicable for TxDataSource with a XA connection pool, not a regular
connection pool.
Which driver are you using?
thanks Priscilla. Ok, so I won't mess with these parameters :-). Are you
confirming that they have nothing to do with the following behaviour :
1/ Start a transaction (entry of transaction-demarcated method)
2/ get a connection from the pool ,
3/ execute the query,
4/ release the connection
5/ get a connection from the pool ,
6/ execute the query,
7/ release the connection
8/ commit the transaction (exit method)
Then, the pool will show that 2 connections were used (and not one as I was
expecting). Joseph confirmed to me that this behaviour was due to the fact
that the connection is not recycled till the end of the transaction. I was
wondering if it had anything to do with these parameters ?
Thanks
-Vincent
Regards,
Priscilla
Vincent Massol <[email protected]> wrote in message
news:[email protected]...
Thanks Joseph. I would have thought that KeepXAConnTillTxComplete was
controlling this behaviour (it is set to false). Isn't that so ? Do youknow
where I could find information on :
KeepXAConnTillTxComplete (currently set to false)
NeedTxCtxOnClose (currently set to false)
NewXAConnForCommit (currently set to false)
XAEndOnlyOnce (currently set to false)
Thanks
-Vincent
"Joseph Weinstein" <[email protected]> wrote in message
news:[email protected]...
Vincent Massol wrote:
Actually, I forgot to mention that we using the following logic :
1/ start transaction (enter method of session bean which is
transaction
enabled)
2/ Perform several JDBC queries
3/ commit transaction (exit of method)
Thus, is it possible that because we're using a Tx DataSource and
transactions, the DB connections from the pool are not recycled
until
the
commit ?Absolutely.
Also, I've found that there are some parameters related to XA :
KeepXAConnTillTxComplete (currently set to false)
NeedTxCtxOnClose (currently set to false)
NewXAConnForCommit (currently set to false)
XAEndOnlyOnce (currently set to false)
As they are set to false, the connections shouldn't be reserved
until
the
commit, right ?
Can someone explain to me (or point me to some doc) where theseparameters
are explained (I have looked a bit everywhere and couldn't find any
information) ?
Thanks
-Vincent
"Vincent Massol" <[email protected]> wrote in message
news:[email protected]...
Hi,
I am running a test with a single client : the test client send arequests,
wait for the response and when it gets it send another request and
so
on.
Looking at the connection pool, I can see that up to 8 DB
connections
(connection high column in the WL console) have been used during
the
test
and I'm wondering why.
Our code has the following logic :
- get connection from pool
- execute query
- release connection (done in a finally block)
We're 100% sure the connections get put back in the pool after
each
request. Is it possible that it would take some time before theconnection
is put back in the pool which would explain why we use more than 1
connection ?
Thanks
-Vincent
B.E.A. is now hiring! (12/14/01) If interested send a resume to
[email protected]
DIRECTOR OF PRODUCT PLANS AND STRATEGY San Francisco,
CA
E-SALES BUSINESS DEVELOPMENT REPRESENTATIVE Dallas, TX
SOFTWARE ENGINEER (DBA) Liberty
Corner,
NJ
SENIOR WEB DEVELOPER San Jose, CA
SOFTWARE ENGINEER (ALL LEVELS), CARY, NORTHCAROLINA San Jose, CA
SR. PRODUCT MANAGER Bellevue, WA
SR. WEB DESIGNER San Jose, CA
Channel Marketing Manager - EMEA Region London, GBR
DIRECTOR OF MARKETING STRATEGY, APPLICATION SERVERS San Jose, CA
SENIOR SOFTWARE ENGINEER (PLATFORM) San Jose, CA
E-COMMERCE INTEGRATION ARCHITECT San Jose, CA
QUALITY ASSURANCE ENGINEER Redmond, WA
Services Development Manager (Business Development Manager - Services)Paris, FRA; Munich, DEU
SENIOR SOFTWARE ENGINEER (PLATFORM) Redmond, WA
E-Marketing Programs Specialist EMEA London, GBR
BUSINESS DEVELOPMENT DIRECTOR - E COMMERCE INTEGRATION San Jose, CA
MANAGER, E-SALES Plano, TX

Accessing the same stateful session bean from multiple clients in a clustered environment

I am trying to access the same stateful session bean from multiple
          clients. I also want this bean to have failover support so we want to
          deploy it in a cluster. The following description is how we have tried
          to solve this problem, but it does not seem to be working. Any
          insight would be greatly appreciated!
          I have set up a cluster of three servers. I deployed a stateful
          session bean with in memory replication across the cluster. A client
          obtains a reference to an instance of one of these beans to handle a
          request. Subsequent requests will have to use the same bean and could
          come from various clients. So after using the bean the first client
          stores the handle to the bean (actually the replica aware stub) to be
          used by other clients to be able to obtain the bean. When another
          client retrieves the handle gets the replica aware stub and makes a
          call to the bean the request seems to unpredictably go to any of the
          three servers rather than the primary server hosting that bean. If the
          call goes to the primary server everything seems to work fine the
          session data is available and it gets backed up on the secondary
          server. If it happens to go to the secondary server a bean that has
          the correct session data services the request but gives the error
          <Failed to update the secondary copy of a stateful session bean from
          home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          to the primary server will not reflect changes made on the secondary
          and vice versa. If the request happens to go to the third server that
          is not hosting an instance of that bean then the client receives an
          error that the bean was not available. From my understanding I thought
          the replica aware stub would know which server is the primary host for
          that bean and send the request there.
          Thanks in advance,
          Justin


          If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
          do you?
          Except of course if you switch ejb containers. Oh well.
          Mike
          "FBenvadi" <[email protected]> wrote:
          >I've got the same problem.
          >I understand from you that concurrent access to a stateful session bean
          >is
          >not allowed but there is a
          >token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
          >that
          >does exactly what I need.
          >What you mean 'you'll get a surprise when you go to production' ?
          >I need to understand becouse I can still change the design.
          >Thanks Francesco
          >[email protected]
          >
          >"Mike Reiche" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Get the fix immediately from BEA and test it. It would be a shame to
          >wait
          >until
          >> December only to get a fix - that doesn't work.
          >>
          >> As for stateful session bean use - just remember that concurrent access
          >to
          >a stateful
          >> session bean is not allowed. Things will work fine until you go to
          >production
          >> and encounter some real load - then you will get a surprise.
          >>
          >> Mike
          >>
          >> [email protected] (Justin Meyer) wrote:
          >> >I just heard back from WebLogic Tech Support and they have confirmed
          >> >that this is a bug. Here is their reply:
          >> >
          >> >There is some problem in failover of stateful session beans when its
          >> >run from a java client.However, it is fixed now.
          >> >
          >> >The fix will be in SP2 which will be out by december.
          >> >
          >> >
          >> >Mike,
          >> >Thanks for your reply. I do infact believe we are correctly using
          >a
          >> >stateful session bean however it may have been misleading from my
          >> >description of the problem. We are not accessing the bean
          >> >concurrently from 2 different clients. The second client will only
          >> >come into play if the first client fails. In this case we want to
          >be
          >> >able to reacquire the handle to our stateful session bean and call
          >it
          >> >from the secondary client.
          >> >
          >> >
          >> >Justin
          >> >
          >> >"Mike Reiche" <[email protected]> wrote in message
          >news:<[email protected]>...
          >> >> You should be using an entity bean, not a stateful session bean
          >for
          >> >this application.
          >> >>
          >> >> A stateful session bean is intended to be keep state (stateful)
          >for
          >> >the duration
          >> >> of a client's session (session).
          >> >>
          >> >> It is not meant to be shared by different clients - in fact, if
          >you
          >> >attempt to
          >> >> access the same stateful session bean concurrently - it will throw
          >> >an exception.
          >> >>
          >> >> We did your little trick (storing/retrieving handle) with a stateful
          >> >session bean
          >> >> on WLS 5.1 - and it did work properly - not as you describe. Our
          >sfsb's
          >> >were not
          >> >> replicated as yours are.
          >> >>
          >> >> Mike
          >> >>
          >> >> [email protected] (Justin Meyer) wrote:
          >> >> >I am trying to access the same stateful session bean from multiple
          >> >> >clients. I also want this bean to have failover support so we want
          >> >to
          >> >> >deploy it in a cluster. The following description is how we have
          >tried
          >> >> >to solve this problem, but it does not seem to be working. Any
          >> >> >insight would be greatly appreciated!
          >> >> >
          >> >> >I have set up a cluster of three servers. I deployed a stateful
          >> >> >session bean with in memory replication across the cluster. A client
          >> >> >obtains a reference to an instance of one of these beans to handle
          >> >a
          >> >> >request. Subsequent requests will have to use the same bean and
          >could
          >> >> >come from various clients. So after using the bean the first client
          >> >> >stores the handle to the bean (actually the replica aware stub)
          >to
          >> >be
          >> >> >used by other clients to be able to obtain the bean. When another
          >> >> >client retrieves the handle gets the replica aware stub and makes
          >> >a
          >> >> >call to the bean the request seems to unpredictably go to any of
          >the
          >> >> >three servers rather than the primary server hosting that bean.
          >If
          >> >the
          >> >> >call goes to the primary server everything seems to work fine the
          >> >> >session data is available and it gets backed up on the secondary
          >> >> >server. If it happens to go to the secondary server a bean that
          >has
          >> >> >the correct session data services the request but gives the error
          >> >> ><Failed to update the secondary copy of a stateful session bean
          >from
          >> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          >> >> >to the primary server will not reflect changes made on the secondary
          >> >> >and vice versa. If the request happens to go to the third server
          >that
          >> >> >is not hosting an instance of that bean then the client receives
          >an
          >> >> >error that the bean was not available. From my understanding I
          >thought
          >> >> >the replica aware stub would know which server is the primary host
          >> >for
          >> >> >that bean and send the request there.
          >> >> >
          >> >> >Thanks in advance,
          >> >> >Justin
          >>
          >
          >

How to get the last used session id for a browser session

In HTMLDB 2.0 it is not possible to start a page with authentication without a SESSION_ID and when you start a public page without a SESSION_ID, then every time a new SESSION_ID is generated when you don't use the SESSION_ID in the URL.
In the same browser session I want to make a URL call to a HTMLDB page without a SESSION_ID and this page has to give back the last used SESSION_ID.
How can I do that?

Fred - You could record that session ID in a table. Each time your authenticated application runs, it would update that table with the "latest" session ID, perhaps using an application process. Then when you are formulating the URL to the public page from another application, you'd get the session ID from that table. Or you could use the page sentry component of your app's authentication scheme to send a cookie to the browser on every page view. The cookie would contain the session ID and the other application could access the cookie to complete the URL.
Scott

How to open a URL without session ID and reuse the current browser session?

Hi All,
I have a question about HTMLDB 2.0
How to open a URL without session ID and reuse the current browser session?
That was the behaviour in HTMLDB 1.6 ...
My usecase for this is the following:
We have written an issue tracking application, which sends e-mail to the interested users, when something happens.
In these email we've put a link to some page, with some parameters in the URL.
The idea is for the user to be easy to click on the hyperlink and to see the details of the ticket.
When the user clicks on such a link he is directed to a login screen (page 101) and he enters his Username and password, and is then forwarded to the details for the ticket.
Then he receives another email (e.g. for another ticked). He clicks on the link and :
a) in HTMLDB 1.6 he goes to the details as he didn't close his browser and session is remembered
b) in HTMLDB 2.0 he is prompted to enter username, password with the username populated
Please tell me how can I achieve the same behaviour in HTMLDB2.0 as it was in HTMLDB 1.6.
I understand this change is somehow security related, althogh I don't understand how. If you can explain this either I would be very happy?
Best regards,
Mihail Daskalov

Mihail - I detailed a couple of approaches here: Re: Application Link
Scott

PL/SQL web service--all users share the same database session

Hi, Is anyone else running into this? If I set a package variable in a pl/sql package through the web service from one client and then connect with another client, I can see the value of the package variable set by the first client. So it appears that instead of being 'stateless', as the documentation claims, that all users are actually connecting to the very same session--and sharing the same memory and variable values.
When I test my application by myself, I don't run into any problems. But the application I'm working on allows over 1000 students to select dorm rooms concurrently. The timing for that large a group is fine enough that I do have more than one person executing the same section of code simultaneously. This is a serious problem! I'm going to try using pragma serially reuseable on my packages to see if that will take care of it.
Has anyone else run into this problem? What do you do about it? Is this an issue with the web service? Or the application server?

Hello!
I have a question. You seem to be getting somewhere. In the reference (in your post) there is no mention of web.xml Is it a generated file or a file created by you? I am getting IOException error when generating EAR file. What could be wrong? Please help
TAI
habeeb

The pooled JMS session is enlisted in another transaction error

Similar Messages

Maybe you are looking for