In presence of continuations, {{try { ... } finally { ... }}} is not sufficient, because you might enter/exit the block multiple times and try/finally only provides hook for exit, but not for entering. This is somewhat related to the hooks on marshalling in that you might need to open and close resources, but applies even when you don't want to serialize the state.
Scheme provides a solution in form of dynamic-wind, which allows one to specify hooks for both before and after blocks.
This also brings up the problem that there are huge amount of Java libraries totally unprepared for the fact that someone might capture the continuation in a callback method and return from the callback several times. This is certainly a problem in container environment: if the container is not aware of continuations and application inside it makes judicious use of continuations, the application could wreak havoc upon the container.
Synchronization is also an issue with continuations: clearly you don't want to keep the currently held locks when capturing a continuation. On the other hand, you don't want to deadlock when reactivating the continuation later on (which could happen if you just try to blindly grab a lock to all objects).
Kent Pitman has an article on UNWIND-PROTECT vs Continuations which discusses some of these issues. Dorai Sitaram wrote a paper UNWIND-PROTECT in portable Scheme that also has a take on the issue.