IMHO that's a somewhat strange scenario, but anyway:
I think that there's no easy way to do this.
If it is ok for the changes in the invalid objects to be lost, then you could call entityManager.refresh(object) for these objects.
If you are using hibernate, you could fall back to the hibernate api for removing single instances from the persistence context (err, hibernate session):
(or something like that - haven't tested it).
Of course after that you have detached objects that are never going to automatically get flushed to the DB again :-(
You can then merge them when their changes should be persisted later.
By far the best solution would be to argue you user/client into changing the requirements - but I know all too well, that often this isn't possible.
Thanks for reply.
I think this is often common scenario.
I thought it wouldn't be easy :)
I solved it with ordinary persistence context (leaving use of seam managed persistence context).
Entities are not merged after each method call, so I decide what entity to persist and when.
I can't use because changed values are lost.
Your best bet here is to make changes to a copy of the entities and then migrate those changes onto the managed entities when they are ready, at which time a flush occurs. Please note that you never have to use merge() if the persistence context stays open. That method is only needed to bring detached entities back into a persistence context (and the database).