WLPS/WLCS 2.0.1: Performance tip

Question

Performace tip for WLCS 2.0.1 [User.getProperty() vs
CachedProfileBean.getProperty()]:
JSP programmers should take advantage of speedy user property
retrieval from the local cache by using the "useCache=true"
attribute with the JSP tags <um:getproperty> and <um:setproperty>
(http://e-docs.bea.com/wlcs/p13ndev/jsptags.htm#1058056 ).
If you are getting and setting user properties in a servlet then
you should prefer the methods of
com.beasys.commerce.user.jsp.beans.CachedProfileBean over
com.beasys.commerce.axiom.contact.User so that you can take
advantage of caching. Even on the first invocation of
CachedProfileBean.getProperty() it is significantly faster than
User.getProperty(). Subsequent invocations of
CachedProfileBean.getProperty() are orders of magnitude faster. The
CachedProfileBean is what the JSP tags use.
A separate CachedProfileBean is instantiated for each user whose
profile is to be manipulated. See the attached javadoc for the
details of instantiating a CachedProfileBean for a
com.beasys.commerce.axiom.contact.User versus a Unified User Profile
(UUP) user of your own creation. If you want to use the
CachedProfileBean in a clustered environment then you need to keep
an instance in each user's session to make it cluster-aware. For
example, if you want to set a user property then you should retrieve
the CachedProfileBean from the user's HttpSession, use
setProperty(), and return the CachedProfileBean to the session. Of
course, when you get a property you should retrieve the
CachedProfileBean from the user's session instead of instantiating a
new one.
If you use the CachedProfileBean in a t3 client or in a servlet
deployed on a server that is not WLCS/WLPS then you will have to set
the environment property "commerce.properties" to
"weblogiccommerce.properties". The CachedProfileBean needs
weblogiccommerce.properties to figure out where to do JNDI lookups.
You can set this property on the command line when you start your t3
client (or server) like this:
java -Dcommerce.properties=weblogiccommerce.properties MyT3Client
The CachedProfileBean was not javadoc'ed for the WLCS 2.0.1
release. It was javadoc'ed for the WLCS 3.1.1 release, but changes
were made between releases. The javadoc for the WLCS 2.0.1 release
is attached.
Thank you for using WebLogic.
Ture Hoefner
BEA Systems, Inc.
2590 Pearl St.
Suite 110
Boulder, CO 80302
www.bea.com
[att1.html]
[WLCS201_CachedProfileBean_javadoc.zip]

Answer 1

Here's a follow-up related to User.setProperty( ) vs.
CachedProfileBean.setProperty( ).
To reiterate what Ture stated, CachedProfileBean is preferred over User
because property values can be retrieved from the local cache. However,
when setting properties, CachedProfileBean can be slower if you're doing a
number of set statements in a row. Here's why.
User is an entity bean. The CachedProfileBean lives in the session; it's
purpose is to avoid using the User entity bean unless it has to (since
entity beans generally mean poor performance).
As the number of references to an entity bean grows, the risk of deadlock
increases. For this reason, the CachedProfileBean doesn't have a reference
to the user entity bean. The setProperty method of CachedProfileBean needs
to first get a reference to the entity bean, then update the property. This
is what can make it slower than User.setProperty( ). If the setInCache
parameter is true, it will also set the value in the cache.
We advise against using the User.setProperty( ) method, especially for
highly shared entity beans, since deadlocks may occur. For example, avoid
using User to set a property for a user that has a Group specified as a
successor; Groups are highly shared entity beans, increasing the chance of
deadlock.
You generally should not mix User.setProperty( ) and
CachedProfileBean.getProperty( ). Since User.setProperty( ) updates the
database but not the cache, you may be left with a dirty cache.
Our best advice is to stick with CachedProfileBean, but wrap all your set
statements in a transaction (e.g., javax.transaction.UserTransaction).
There are two benefits of this. First, all the sets will succeed or fail as
a unit. Second, you'll see a performance gain since you're saving on
database connections. If you have a large number of set statements in a
row, you will see a significant performance increase if you wrap them in a
transaction, since you're only using one database connection rather than one
per set statement.
- Ginny