The EJB3 specification has removed the notion of TRANSACTIONAL EntityManager when the EntityManager is application managed.
In other words, all application-managed EntityManager are considered EXTENDED.

Do you use this feature? Is it useful for you?

Of course Container Managed EntityManager still support TRANSACTIONAL and EXTENDED.

Does this have the advantage (as is the case with a RESOURCE Local EntityManager) that on throwing an exception and (because of bad programming style) not rolling back, or committing your transaction one does not have a database lock hanging around?

I foresee that lot's of people in a J2SE environment forget such things (I did) and get into problems, because no-one is going to end the transaction and maybe lots of people are waiting on it.

So am I right that that cannot happen with an JTA EntityManager? Or why did the EJB3 Persistence experts decide to do this?

not commiting nor rollbacking and subsequent issues are orthogonal concerns and are not really related to the TRANSACTIONAL / EXTENDED question.

I guess this can happen in a JTA EM if you use user managed transaction unless the JTA implementation does some kind of smart garbage collecting.

This cannot happen when you use Container managed transaction.
So in J2SE use JBoss Embeddable EJB3 and you are back to EE :-)

Ok,

but why then was the Resource local EntityManager removed for J2SE?
And what should I do if I have other users of my database and I want to do pessimistic locking?

(note to self: read more about JTA)

I think this link to the current EntityManager documentation is usefull

http://www.hibernate.org/hib_docs/entitymanager/reference/en/html/transactions.html

I understand that the spec is still under development but it now states that it uses Optimistic Locking, which is with the current Hibernate Entity Manager not the case. If I take a default MS SQL SRV2000 + jTDS + Resource Local EntityManager my test waits for the previous transaction to close. This is not what the spec says:

In 3.3.5 Optimistic Locking and Concurrency

This specification assumes the use of "optimistic locking". It assumes that the databases to which persistence
units are mapped will be accessed by implementations using read-committed isolation (or a
vendor equivalent in which long-term read locks are not held), and that writes to the database typically
occur only when the flush method has been invoked—whether explicitly by the application, or by the
persistence provider runtime in accordance with the FlushMode settings. If a transaction is active, a
compliant implementation of this specification is permitted to write to the database immediately (i.e.,
whenever a managed entity is updated, created, and/or removed), however, the configuration of an
implementation to require such non-deferred database writes is outside the scope of this specification.
The configuration of the setting of optimistic lock modes is described in section 3.3.5.3. Applications
that prefer the use of pessimistic locking may require that database isolation levels higher than
read-committed be in effect. The configuration of the setting of such database isolation levels, however,
is outside the scope of this specification.

(The whole chapter 3.3 of the Proposed Final Draft makes for interesting reading about this subject. If you don't have it, get it here: http://www.jcp.org/en/jsr/detail?id=220

How is your question related to the persistence context type? It is not possible to lock an entity when no transaction is in process anyway.

Well, I have tried with my very limited knowledge to guess why this change was proposed.

My last guess (please correct me if I'm wrong) is that a typical setup with EJB3 J2SE is a used in this way:

Database server + Hibernate Optimistic Locking and Level 2 cache + database connection in READ_COMMITED isolation mode

You are then using extended transactions and you do not have the risk of starvation OR of dead locks, only of OptimisticLockException, if you commit to late

If anyone thinks there is another reason or a better setup, I'd like to read your explanation why it will be removed from the spec as well. (When will the final spec be released by the way?)