So, your ENFE exception is propagated to the nester of the EJB? If a runtime exception gets thrown pass an EJB boundary then the transaction is marked for rollback.
You can't get around this. Refactor your code to use find() and check for NULL or catch the ENFE exception within the nested EJB call and wrap it with a non-rollbacking exception (checked or runtime annotatied with @ApplicationException(rollback=false)), or, just change the contract of your nested EJB invocation.
That's unfortunate for me. How can you use find with a native SQL query? I think that using @ApplicationException(rollback=false) will not be so great for me because the Exception I am raising should rollback transactions under certain circumstances. I know I could create two different exceptions, but that doesn't feel right.
If I demarcate the first operation as requiring a new transaction, thereby nesting the transaction, and then it throws an exception that I catch will the parent trans rollback?
that won't work either as you won't have the same persistence context and the returned entity won't be managed anymore.
I fhink you need to rearchitect your API as suggested above.
BTW, your scenario is exactly the reason why the spec has
find() which returns null
and getReference() which throws an ENFE.
Again, unfortunately find is not an option because I use native sql. I have moved an existance check into my stored proc and it works fine now. It is not ideal, but it works.