Does TransactionAttributeType.NOT_SUPPORTED make sense for retrieving entities?

问题

Does having TransactionAttributeType.NOT_SUPPORTED on every DB lookup method makes sense? I don't see the point in having the entity attached if it's not going to execute an update.

@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
pubic List<AnEntity> getListEntities(){
    TypedQuery<AnEntity> query = em.createNamedQuery("AnEntity.myQuery",AnEntity.class);
    return query.getResultList();
}

Does it still end up in the cache?

The only time it seems useful to use the REQUIRED transcation propagation is when an update is required:

 @TransactionAttribute(TransactionAttributeType.REQUIRED)
 public void editPersonName(Integer id, String newName){
      AnEntity anEntity= em.find(AnEntity.class, id);
      anEntity.setName(newName);
 }

Other than that I don't really see the point.

回答1:

No, it doesn't make sense to use the NOT_SUPPORTED transaction propagation for read-only queries, but it makes a lot of sense to use the default REQUIRED transaction propagation. You need a transaction for reading data too. The database always uses a transaction, no matter if you specify it or not.

Using an explicit transaction allows you to group several statements in a single transaction, and, if you are using Hibernate, you might avoid the aggressive connection release overhead.

Just because JPA allows you to executed read queries without a transaction, it doesn't mean you have to do it this way.

The NOT_SUPPORTED mode is useful when you want to execute a service method outside of the current transaction scope and that's useful for methods that don't need a transaction at all (e.g sending an email) so that you avoid the overhead of starting/ending a transaction context.

来源：https://stackoverflow.com/questions/35263091/does-transactionattributetype-not-supported-make-sense-for-retrieving-entities