1) Subclass and customize
2) You can't (that is good, there is no overhead if no transactional resources are used)
3) Committing after INVOKE APPLICATION and opening a second transaction in RENDER RESPONSE (which usually only reads data) keeps locks in the database, created from inserts, updates, and deletes during INVOKE APPLICATION, as short as possible
3/ ok, i know why do you commit the first one, but do you need a transaction to read data?
ok, tnx... but one more:
2/ what if i have to call a session bean method annotated with @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)