'Supports' vs 'Notsupported' for a non-TX method


EJB programming & troubleshooting: 'Supports' vs 'Notsupported' for a non-TX method

  1. Hi,
    I am unable to decide between using 'Supports' and 'NotSupported' for a Stateless Session Bean method that does not do any DML operations (directly or indirectly).

    If 'NotSupported' is specified, I am told that there is a small overhead for suspending and resuming the client's transaction context.

    And if 'Supports' is specified - we avoid this overhead, but I am told that there is a cost for 'monitoring' the non-transactional DB statements (SELECTs, to be precise).
    So which is better? Or are there other issues to consider before deciding?

    And while I am here, I want a good example for a situation that suggests the use of 'Supports' attribute. (esp. considering the fact that 'Supports' methods behave in a chameleon kind of way wrt transactions)

    Grateful for any inputs.
  2. I tend to use "Supports" for read-only operations. That way, if read operations are all that are invoked, there are no transactions and the reads can execute concurrently. If a write operation is involved (for which I use the "Required" attribute), the read-only operation because part of a transaction, to ensure that the values read to not change during the operation.

    I would advocate using "Supports" over "NotSupported", unless you have a good reason to do otherwise.
  3. I would stick to Supports option. This is especially true for different types of clients, and when the Session bean is really 'componentisised', e.g. it is called both by other components in the server/cluster and by external clients (GUI, Web).
    'Supports' would be a nice compromise for those.

    But, if you never intend to run with a transaction, use NotSupported option. Believe me, involving a component in a transaction is a much greater overhead than pausing the already running one.

    Best regards,
  4. Thank you all for your inputs.

    But still I am looking for example of a natural situation that would need the 'Supports' attribute to be used. I mean, we all know when to go for 'Required' and 'RequiresNew'... but 'Supports', due to its dual behaviour, is somewhat dangerous to use without analysing all the client calls... why do they have this attribute at all, in the first place? Just to complete the list?
  5. Situation for 'Supports' usage[ Go to top ]

    I gave you one option for the "Supports" attribute: read-only methods (getters).

    And it is not that dangerous. While your application is in "read-only" mode, with nothing but getters being invoked, there are no transactions and all operations can occur concurrently (and quickly).

    However, if a read operation is invoked together with a write operation (with the "Required" attribute), a transaction will be started, and the read operation will participate in that transaction. The resources read will be locked until the transaction is complete.