Not sure this is a good idea, because you _want_ to break repeatable read isolation of your conversation/transaction. But you can with a scalar query, a query that doesn't return entity instances (which would hit the persistence context cache): select e.statusProperty from MyEntity e
This goes straight to the database and returns this value, the only cache that could be between you and the data is the Hibernate second-level query cache (which isn't enabled by default).
Btw, this is usually solved with versioning and automatic optimistic locking: You'd get a StaleObjectState (or the equivalent EJB3 exception) when you try to save and someone else modified the same row.
Versioning and optimistic locking is also immune to the inevitable race condition of checking for changes before a commit. It does throw an exception though, which makes recovery like offering a "merge" screen somewhat complicated.
Sometimes you still might want to peek outside the current transaction, like if you wanted to poll for changes during an edit session and show a warning. A query in a different entitymanager (like one you get from @PersistenceContext or from JNDI) ought to do the trick, no?