In the EJBs of the Pet Store is coded a (or several) JNDI name(s) (don't
know which in this moment). This name must mach to the given name of an
"ejb-location" of orions data-source, not to the given name of "location".
If accidently this _name_ in the pet store is "location", you should set
ejb-location="jdbc/location". If by now the pet store used the "naked
location", you should observe significant performance gains. And - what's
more - only with the ejb-location transactions can be rolled back properly.
Jens
> -----Ursprüngliche Nachricht-----
> Von: Kirk Kalvar [mailto:[EMAIL PROTECTED]]
> Gesendet am: Dienstag, 4. Juli 2000 23:59
> An: Jens Stutte
> Betreff: RE: Update: Performance & Scalability
>
> Jens:
>
> Thanks, that did clear things up a bit. I think xa-location refers to
> X/OPEN DTP transaction resource interface (known as XA).
>
> Sun's Java Pet Store 1.0 (jps) application is using
> "location". What would
> happen if I changed to ejb-location? Any additional coding?
> Performance
> gains?
>
> Kirk S. Kalvar
> email [EMAIL PROTECTED]
> phone 703-591-3361
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jens Stutte
> Sent: Tuesday, July 04, 2000 1:26 PM
> To: Orion-Interest
> Cc: '[EMAIL PROTECTED]'
> Subject: AW: Update: Performance & Scalability
>
> Hi Kirk,
>
> i assume he confused (like me some time ago) the different
> jndi names for
> the database connections. In a data-source you specify
> different locations,
> which will be treated differently by the server. The
> "location" is a 'naked'
> standard JDBC connection without pooling or anything. The
> "ejb-location"
> provides server specific wrapper classes for the connections,
> which provide
> such things as pooling, transaction handling for EJBs etc. I
> don't know the
> specific purpose of the "xa-location" and when to use it. Anyway, from
> within EJBs you should always use the "ejb-location".
>
> Regards,
>
> Jens Stutte
>
> PS: Example of a data-source:
> <data-source
> name="BaseDB"
> class="com.evermind.sql.ConnectionDataSource"
> location="jdbc/BaseDB"
> xa-location="jdbc/xa/BaseXADB"
> ejb-location="jdbc/BaseEJBDB"
> inactivity-timeout="60"
>
> url="jdbc:informix-sqli://beatnix.net-media.de:1536/BaseDB:INF
> ORMIXSERVER=on
> _beatnix"
> connection-driver="com.informix.jdbc.IfxDriver"
> username="informix"
> password="topsecret"
> />
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Kirk Kalvar [mailto:[EMAIL PROTECTED]]
> > Gesendet am: Dienstag, 4. Juli 2000 17:19
> > An: Orion-Interest
> > Betreff: RE: Update: Performance & Scalability
> >
> > Tom:
> >
> > Could you be more specific? You weren't accessing the db
> > connection pool, but what did you do to fix it?
> >
> > Thanks in Advance,
> >
> > Kirk S. Kalvar
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 04, 2000 9:27 AM
> > To: Orion-Interest
> > Subject: Update: Performance & Scalability
> >
> > All,
> >
> > In a previous message I expressed my concern about
> > performance as compared with Weblogic 5.1. With
> assistance
> > from Karl Avedal, I made some changes to my
> application
> and
> > am very pleased to announce that Orion is
> approximately 2x
>
> > faster than Weblogic 5.1.
> >
> > I wasn't using the DB connection pool and
> it is a pleasure
> to
> > work with a product that does conform and
> support the
> latest
> > J2EE specification.
> >
> > In general, migrating from WL to Orion has
> been pretty
> > painless. Most of the changes were
> container specific,
> > config files, etc. and no code changes.
> The only code
> > changes I'm now going to make has to do
> with improving my
> > code. This exercise has identified areas that were
> > inefficient or were specific to WL.
> >
> > BTW, my evaluation of Orion and two other
> Ejb servers has
>
> > resulted in Orion as my choice hands down.
> >
> > Thanks
> > Tom
> >
> > Tom Wnuk
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> >
>
