Hi Phil,

----- Original Message -----
From: "Phil Warrick" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 01, 2003 12:34 AM
Subject: Re: [jBoss] multiuser problems


> 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?

I like this question. The answer is: NO ;-)
If you need clustering in the future you can switch
to SequenceManagerNextValImpl without problems
(when using e.g. Oracle).

regards,
Armin

>
> 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]
>
>



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

Reply via email to