question about sticky load balancing

[fox hk]

Hi all
It is very thankful some one can provide me with answer to following questions. The iAs is version 6.5
1) If a component is set using "sticky load balancing". Requests of same sessin will be sent to same JVM. If my app is composed of jsp/servlet, session and entity bean. Will all calls from jsp/servlet to session and entity bean happen in same JVM if sticky load balancing is used? (As you see, it is not a must for entity/session bean reside in same JVM).
2) If not so, is there any way to configure the ias to achieve the invocations of same session -- (servlet/jsp --> stateful/stateless session bean --> entity bean)almost happen in same JVM
3) If l remember correctly that ias6.5 only support "commit-option" C, is there any way to leverage cache machanism in persistence layer
thx a lot
fox hk

[David Ogren]

iAS will always attempt to service requests for EJBs from the same JVM the request is being made from. This vastly improve performance by co-locating the request.
This means that if you make your web application sticky, that you will also make your EJB requests sticky in the architecture you describe. Remember, however, that it really shouldn't matter where a SLSB or Entity bean executes. A SLSB should be stateless. And a Entity Bean should always be in sync with the persistent data it is modeling. So you should always get the same results from your EJB, no matter where it executes. Stickiness should really only be a performance factor.
As you point out, iAS supports Commit option C. Which specifically excludes the types of caching you are talking about. I will point out a couple of things that might help. Firstly, if you are using BMP, the fact that the container is required to invoke the ejbStore and ejbLoad callbacks does not mean that you have to do anything in those callbacks. For example, you could place some kind of cache detection mechanism in ejbLoad and make ejbLoad retrieve from cache when a cache is available and fresh. Alternatively, if you are using CMP, you could investigate third-party CMP implementations such as Cocobase that have more sophisticated cache management and commit option support.
David

[fox hk]

Dear David
thank you very much for your detailed explanation. But l still have a few questions, it is highly appreciated you can drop a few comments on them.
1) As l checked the manul, your book and ias samples, it seems that only the servlet can be set sticky as following eg in ias-web.xml file.
Is there any similar tag in ias-ejb-jar.xml which is used for enabling the sticky behaviour of session/entity bean ? Or setting the servlet "sticky" can make all calls to EJB from this servlet happen within same JVM ?
<servlet>
<servlet-name>populateServlet</servlet-name>
<guid>{396803E0-246D-11D5-A09C-0010A4C4735E}</guid>
<validation-required>false</validation-required>
<servlet-info>
<sticky>true</sticky>
<encrypt>false</encrypt>
<number-of-singles>10</number-of-singles>
<disable-reload>false</disable-reload>
</servlet-info>
</servlet>
2) If there are many servlets defined in my web.xml, not all servlets are set as "sticky" but all of them will reference "httpsession" object. what happen ? Is there any difference if
"lite" or "distributed" is used for "session-info" tag.
<session-info>
<impl>lite</impl>
........

[David Ogren]

Let me try again.
The appserver, in all but a few rare cases that don't apply here, will always process EJB requests in the same JVM that makes the EJB request.
So: if all of my servlet/JSP requests are going to a particular JVM (because my session is sticky), and all of the EJB requests that are made by those servlets and JSPs will be handled by the same JVM that hosts the servlet/JSP, then we can conclude that all of the EJB requests will effecively be sticky as well, just because the co-location.

If there are many servlets defined in my web.xml, not all servlets are set as "sticky" but all of them will reference "httpsession" object. what happen ?

I talk about this on page 312 of the book, but in short, the requests are not sticky until the first sticky component is requested. Once the first sticky component is requested all requests are sticky, even those for non-sticky components.

Is there any difference if
"lite" or "distributed" is used for "session-info" tag.

The session implementation does not affect load balancing. However, if you aren't using stickiness then lite sesisons are very effective since they aren't distributed. So until your user's session becomes "stuck" HttpSession will not be reliable. This may or may not be OK, depending on your application.
David

[fox hk]

Dear David
thank you very much for your quick reply. After l deployed the petstore app installed along with ias, l came across some puzzling setting. It is very thankful you can give me some idea why it is this case.
1) according to admin / developer guide of ias6.5, it seems that ias6.5 only supports commit option c. But l find following setting in a ias-ejb-jar.xml
<entity>
<ejb-name>TheOrder</ejb-name>
<guid>{701A16D4-352F-18AB-E469-080020877B69}</guid>
<pass-timeout>0</pass-timeout>
<is-thread-safe>false</is-thread-safe>
<pass-by-value>false</pass-by-value>
<pool-manager>
<factory-class-name></factory-class-name>
<commit-option>COMMIT_OPTION_B</commit-option>
<Ready-pool-timeout>0</Ready-pool-timeout>
<Ready-pool-maxsize>0</Ready-pool-maxsize>
</pool-manager>
Also at p423 of "devloper's guide", l found following setting
<entity>
<ejb-name>TheAccount</ejb-name>
<guid>{deadbabe-ab3f-11d2-98c5-999999990000}</guid>
<pass-timeout>100</pass-timeout>
<is-thread-safe>false</is-thread-safe>
<pass-by-value>false</pass-by-value>
<pool-manager>
<commit-option>NO_CACHE_READY_INSTANCE</commit-option>
<Ready-pool-timeout>0</Ready-pool-timeout>
<Ready-pool-maxsize>0</Ready-pool-maxsize>
</pool-manager>
why ?
2) Also, in ias-web.xml, l found following
<session-info>
<impl>lite</impl>
<dsync-type>dsync-local</dsync-type>
<timeout-type>last-access</timeout-type>
<secure>false</secure>
But after petstore was deployed, l found at iAST, mode of the application components of pestore.war package (webTierEntryPoint and populateServlet) are set to "distributed". Why ?
Also, what does "dsync-local" mean ? does this mean this app will not support failover as deployed to iAS
3) where can l find the DTD of all xml configuration files needed for iAs. Some info can be found at the developer's guide. But the problems with the dev's guide seems not that detailed. Because in Q1 l raised out, the dev guide doesn't mention such values are supported for those tag.
thanks a million !
fox

[David Ogren]

The commit B reference must be a typo in the DTD of the Pet Store. iAS will accept Option B as a viable option, but it is not supported and iAS will treat it as Option C.
DSYNC-Local means that sessions are stored in the DSYNC engine of the KXS, but they are not distributed to other KXS's. So you will have session failover within the instance (from KJS to KJS) but not across instances.
David