Re: [jBoss] multiuser problems

Mon, 30 Jun 2003 15:27:54 -0700

Hi Armin,

I changed the sequence manager to SequenceManagerInMemoryImpl and everything looks good so far. The clue for me was that read operations were also having problems under multi-user conditions, and even they require updating the OJB_HL_SEQ table. I should have heeded your suggestion long ago to avoid SequenceManagerHighLowImpl...

I don't foresee a need to cluster (at least for the moment), and there is no db-based sequencing happening outside my app, so are there any downsides to using SequenceManagerInMemoryImpl?

Thanks,

Phil

Armin Waibel wrote:
Hi Phil,


> - exhausted DataSource pool (db-connection pool, jboss)?

I use default settings for the OracleDS, should this be changed in
oracle-service.xml?



I'm not a database guy, but on second thoughts I think this
can't be the problem (missing exhausted/timeout exception).

On the dev list some user reported about a deadlock
http://article.gmane.org/gmane.comp.jakarta.ojb.devel/2971
maybe this will solve your problem too.

regards,
Armin

----- Original Message -----
From: "Phil Warrick" <[EMAIL PROTECTED]>
To: "Phil Warrick" <[EMAIL PROTECTED]>; "OJB Users List"
<[EMAIL PROTECTED]>
Sent: Thursday, June 26, 2003 4:36 AM
Subject: Re: [jBoss] multiuser problems



Hi Armin,

In fact, my oracle-service.xml is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<!--


===================================================================== --

<!--
   -->
<!--  JBoss Server Configuration
   -->
<!--
   -->
<!--


===================================================================== --


<server>

<!--


==================================================================== -->

  <!-- ConnectionManager setup for Oracle dbs
     -->
  <!-- Build jmx-api (build/build.sh all) and view for config
documentation -->
  <!-- Thanks to Steven Coy
     -->
  <!--


==================================================================== -->

  <mbean
code="org.jboss.resource.connectionmanager.LocalTxConnectionManager"
name="jboss.jca:service=LocalTxCM,name=OracleDS">


    <!-- Include a login module configuration named OracleDbRealm.
         Update your login-conf.xml, here is an example for a
         ConfiguredIdentityLoginModule:

    <application-policy name = "OracleDbRealm">
       <authentication>
          <login-module code =
"org.jboss.resource.security.ConfiguredIdentityLoginModule" flag =
"required">
             <module-option name =
"principal">yourprincipal</module-option>
             <module-option name =

"userName">yourusername</module-option>

<module-option name =

"password">yourpassword</module-option>

<module-option name =


"managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=OracleDS
</module-option>

          </login-module>
       </authentication>
    </application-policy>

    NOTE: the application-policy name attribute must match
SecurityDomainJndiName, and the
      module-option name = "managedConnectionFactoryName"
    must match the object name of the ConnectionManager you are
configuring here.
    -->

<!--uncomment out this line if you are using the OracleDbRealm

above

<attribute

name="SecurityDomainJndiName">OracleDbRealm</attribute>

-->

    <depends optional-attribute-name="ManagedConnectionFactoryName">
      <!--embedded mbean-->
      <mbean

code="org.jboss.resource.connectionmanager.RARDeployment"

name="jboss.jca:service=LocalTxDS,name=OracleDS">

<attribute name="JndiName">OracleDS</attribute>

        <attribute name="ManagedConnectionFactoryProperties">
          <properties>
            <config-property name="ConnectionURL"


type="java.lang.String">jdbc:oracle:thin:@127.0.0.1:1521:mondp</config-p
roperty>

<config-property name="DriverClass"


type="java.lang.String">oracle.jdbc.driver.OracleDriver</config-property

            <!--set these only if you want only default logins, not
through JAAS -->
            <config-property name="UserName"
type="java.lang.String">MOND_USER</config-property>
            <config-property name="Password"
type="java.lang.String">MOND_PASS</config-property>
          </properties>

</attribute>

<!--Below here are advanced properties -->
        <!--hack-->
        <depends


optional-attribute-name="OldRarDeployment">jboss.jca:service=RARDeployme
nt,name=JBoss

LocalTransaction JDBC Wrapper</depends>
      </mbean>
    </depends>

    <depends optional-attribute-name="ManagedConnectionPool">
      <!--embedded mbean-->
      <mbean
code="org.jboss.resource.connectionmanager.JBossManagedConnectionPool"
name="jboss.jca:service=LocalTxPool,name=OracleDS">

        <attribute name="MinSize">0</attribute>
        <attribute name="MaxSize">50</attribute>
        <attribute name="BlockingTimeoutMillis">5000</attribute>
        <attribute name="IdleTimeoutMinutes">15</attribute>
        <!--criteria indicates if Subject (from security domain) or

app

supplied
            parameters (such as from getConnection(user, pw)) are

used

to distinguish
            connections in the pool. Choices are
            ByContainerAndApplication (use both),
            ByContainer (use Subject),
            ByApplication (use app supplied params only),
            ByNothing (all connections are equivalent, usually if
adapter supports
              reauthentication)-->
        <attribute name="Criteria">ByContainer</attribute>
      </mbean>

    </depends>
    <depends


optional-attribute-name="CachedConnectionManager">jboss.jca:service=Cach
edConnectionManager</depends>

<depends


optional-attribute-name="JaasSecurityManagerService">jboss.security:serv
ice=JaasSecurityManager</depends>

    <attribute
name="TransactionManager">java:/TransactionManager</attribute>

    <!--make the rar deploy! hack till better deployment-->
    <depends>jboss.jca:service=RARDeployer</depends>

</mbean>


</server>

Hi Armin,

> - sequence manager, which implementation?

SequenceManagerHighLowImpl (I know that you don't suggest it with

JBoss,

but the failure scenario you mentioned a few week ago didn't see to
apply (where a rollback causes problems).  I plan to move towards
dbms-generated sequences, but one step at a time...

> - exhausted DataSource pool (db-connection pool, jboss)?

I use default settings for the OracleDS, should this be changed in
oracle-service.xml?

Phil

Armin Waibel wrote:


Hi Phil,

sounds like a deadlock.


But first a few pointers to help
me in my investigation would be very welcome



- sequence manager, which implementation?
- exhausted DataSource pool (db-connection pool, jboss)?

regards,
Armin
----- Original Message -----
From: "Phil Warrick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 25, 2003 4:46 PM
Subject: [jBoss] multiuser problems




Hi all,

I have a j2ee client app that talks to the database via jboss and

ojb.

This app works fine when there is only one client talking to jboss

at


a


time. It even works fine when I create several pseudo-clients in

the

same app running separate connections in their own threads

(similar to

the ojb ejb stress tests).  However when I run this test with two
separate client machines, each writing to completely different

sets of

objects, things silently hang in jBoss, and I cannot make any

further

remote calls. Note that there should not be a problem of

simultaneous

access to the same persistent object. I need to restart jBoss to

be


up


again.

I realize that I am only giving a general description of the

problem,

and I intend to investigate further so that I have (hopefully)

some

stack traces instead of silent death. But first a few pointers

to


help


me in my investigation would be very welcome.

First my setup is the following:
WinNT - jBoss 3.0.6 - ojb1.0rc2 - Oracle 8.1.6

I've held off moving up to rc3/4 due to the myriad of sequence


problems


that I and numerous other Oracle users experienced with rc3.  I'm
willing to roll up my sleeves and move to rc4 if required (is it
possible that this is a bug that has been address recently -- I

don't

see any bug reports quite like this). Hopefully the sequence

problems

have been addressed by now?

This is the last leg of a long journey to go into production with

ojb

and add another "success story" to the list.

Thanks,

Phil 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to