best strategy in ejb transaction setting - in CMT
Hello -
I am looking for best strategy in the ejb transaction setting. Here is my concern on this:
1): you must specify transaction attribute on all bussiness methods and home interface methods;
so if there are 50 bean each has 5 methods, there will be 250 setting if one by one -- a lot :)
2): transaction causes extra work for container, so we might want to set some methods to NoSpported. -- but some container will not support, portibility issue
3): group small transactions together to one transaction, this can cause a lot maintaince work reduce maitainiblity -- every update, you need to walk through the setting and make sure that the transaction bounary is correct.
So --
We just set all methods to be required?
Please advise with my appreciation!
# 1
1) This doesn't mean that the tx metadata must be specified at the method level.
It just means that in EJB 2.1 and earlier there was no tx attribute default. When
using the ejb-jar.xml to specify tx attributes, there has always been a syntax
that allows for setting the tx attribute at the bean level. E.g.
<container-transaction>
<method>
<ejb-name>FooEJB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
You might also want to consider using EJB 3.0. All EJB 3.0 beans default
to CMT/Required, so there is a lot less metadata to specify.
2) Java EE compliant application servers MUST support all the EJB tx attributes.
If you're using a compliant application server it is definitely portable to use
the NOT_SUPPORTED tx attribute.
3) This guideline does not mean that you should automatically do as little
work per transaction as possible. It just means you should try to avoid
long-lived transaction and that you should think a lot about what grouping
of transactional work makes the most sense for your application and
use-cases.
# 2
>>It just means you should try to avoid long-lived transaction and that
>>you should think a lot about what grouping of transactional work >>makes the most sense for your application and use-cases.
That is exactlly what I am trying to point out. "thinks a lot", so every update, "think a lot" (again) about the groupping.
How to avoid "think a lot"?
# 3
I should make it more precisly:
How to avoid "think a lot":
I know we have to think a lot, that is our value -- we can think. :).
If there is a lot of methods and we need to group them into the transaction group and set right boundary with short transactions is a complete job, that does need to think a lot.
If set all the methods required, let the container to group the transaction based on the current transaction context to determine the transaction boundary, is it less efficient than the group by the user?
