I think it makes sense to think about this in terms of the container's interaction with a caller to the EJB method as a true monitor... so I'd like to use a bouncer metaphor in various different scenarios.
See this page for a good description/overview of the transaction attributes.
Required (REQUIRED @TransactionAttribute)
Night club
Show up at the club, need a ticket to enter. If you don't have one it will be (purchased?) given to you at the door.
Transaction is the TICKET.
Container is the BOUNCER.
Requires New (REQUIRES_NEW @TransactionAttribute)
Comedy clubs, 1 drink-minimum, no re-entry
Show up at the club, no outside food/drink, you must leave them at the door. To get in you must purchase 1-drink minimum every time you leave and re-enter.
Transaction is the DRINK.
Container is the BOUNCER.
Suspending the transaction is LEAVING AT THE DOOR.
Supports (SUPPORTS @TransactionAttribute)
House party
Show up at the party, alcohol is permitted. We'll let you in with it if you have your own alcohol, if you don't we'll let you in too.
Transaction is the ALCOHOL.
Container is the HOST.
Mandatory (MANDATORY @TransactionAttribute)
Invite-only party
Show up at the party, need a invitation to enter: If you don't have one and try to get in, the bouncer calls the authorities.
Transaction is the INVITATION.
Container is the HOST.
Throwing an exception is CALLING THE AUTHORITIES.
Not Supported (NOT_SUPPORTED @TransactionAttribute)
Concert, cameras are prohibited.
Show up at the concert, cameras are prohibited. You can leave it at the door and pick it up when you leave.
Transaction is the CAMERA.
Container is the DOORMAN.
Suspending the transaction is LEAVING AT THE DOOR.
Never (NEVER @TransactionAttribute)
High school dance
Show up at the dance, alcohol is prohibited. If you try to get in with it and are caught, the chaperone calls the authorities.
Transaction is the ALCOHOL.
Container is the CHAPERONE.
Throwing an exception is CALLING THE AUTHORITIES.