Geek Answers Handbook

Stateful session bean pool size

I go through a corporate session bean material.i doubt relatively below: -

1) let's say we mentioned the pool size as 50 for some static bean session. 50 customers use them. so now all 50 beans support some state. At what point will these states be removed so that if the 51st wedge asks for a bean, it will not receive any previous corrupted state.?

2) let's say we mentioned the pool size as 50 for some session without a bean state, and they are all used at some point in time. If the 51st client arrives and asks for a bean, will he wait until some bean is free or create a new bean instance?

+4
source share
2 answers

The beans session is usually not aggregated. It is possible, but their state makes them less ideal for combining, as the client expects a fresh bean when receiving the link.

For idle beans yes, the 51st client will have to wait. This is usually good, as it automatically mitigates the consumption of resources by your system. Depending on your resources, workload and amount of work in one ssb call, you can adjust the size of your pool.

+5
source

As stated in bkail, the semantics of @Stateless beans have vendor specificity. In EJB 3.1, we added the @AccessTimeout annotation, which can be used in the bean class or the @Stateless , @Stateful or @Singleton bean @Singleton .

@AccessTimeout

In a general sense, this annotation portable indicates to what extent the caller will wait if a wait condition occurs while accessing simultaneously. For each bean type, waiting conditions will occur when:

  • @Singleton - The @Lock(WRITE) method is used, and the concurrency container is used. By default, all @Lock(WRITE) methods @Lock(WRITE) .
  • @Stateful - any instance method is called and a second call is made. OR @Stateful bean is in a transaction, and the caller calls it from outside this transaction.
  • @Stateless - There are no instances in the pool. However, as already noted, the union of semantics, if any, is not covered by the specification. If the semantics of the provider association are related to the wait condition, then @AccessTimeout should be applied.

Using

@AccessTimeout is just a convenient wrapper around the long and TimeUnit tuples commonly used in the java.util.concurrent API.

 import java.util.concurrent.TimeUnit; @Target({METHOD, TYPE}) @Retention(RUNTIME) public @interface AccessTimeout { long value(); TimeUnit unit() default TimeUnit.MILLISECONDS; }

If a class or bean method is explicitly specified, it has three possible values:

  • @AccessTimeout(-1) - Never go into standby mode, wait as long as you need. Potentially forever.
  • @AccessTimeout(0) - Never wait. Throw a ConcurrentAccessException immediately if a wait condition occurs.
  • @AccessTimout(30, TimeUnit.SECONDS) - Wait up to 30 seconds if a wait condition occurs. After that throw ConcurrentAccessTimeoutExcpetion

No default default

Note that the value attribute does not have a default value. This was intentional and intended to inform you that if @AccessTimeout is not explicitly used, the behavior you get depends on the provider.

Some sellers will wait for a pre-configured time and throw javax.ejb.ConcurrentAccessException , some sellers will immediately throw it. When we defined this annotation, it became clear that all of us, sellers, did something different, and forced default could cause problems for existing applications.

Similarly, prior to EJB 3.0 there was no default transaction attribute, and it was different for each provider. Thank goodness EJB 3.0 was quite different, and we could finally say: "For EJB 3.0, beans are REQUIRED by default."

+5
source

More articles:


All Articles