I'm having a hard time following this. All I do is go ahead and try and save and catch the OptimisticLockingException if if comes up. No need for specialized overhead. If I've been well-behaved, the operation succeeds. Otherwise, it's Management By Exception, and it's reasonable that exceptional cases require more work than the common ones.
On the other hand, if multiple concurrent modifications are going to be the rule rather than the exception, I'd recommend designing specifically for that problem. The traditional approach is to obtain a (pessimistic) lock, and work with a single copy of that record. You could cache that copy and present it to local app users so they don't end up making conflicting mods (and note that
EJB in particular was designed to synchronize access to bean properties). If you have a mutiple-server situtation, you're better off coughing up cash for a coherent cache such as Tangesol.
In all of the above situations there's no real reason to acquire the underlying object implementation, and some good reasons not to. However, in a pinch, casting is the best solution.
Do realize that there's probably 40 years of real-world experience been laid up by some big names working on some really high-performance systems, and it's better to look at Best Practices than to cook up some one-off solution if you can. Custom solutions are expensive to develop, debug and maintain, with their "real" cost often exceeding what the commercial solutions cost. You have fewer support options as well. If it fails, the person the boss calls up and yells at is probably going to be you. Not meaning that a purchased solution is necessarily the way to go, but at least follow proven paths. I have a very good book in my possession that's entirely dedicated to transaction management in
Java, including in an XA environment.