Well, my first advice always will be: don't do that. The need for a cascaded update is a symptom of bad database design. I described in the
thread I posted earlier how I got burned with mutable primary keys.
There are two ways to temporarily lift constraints in Oracle (as far as I know). It seems you're not differentiating these two ways properly:
1) Disable constraint. This can be done via the ALTER command, but it is a DDL operation and affects all sessions. This is not what you want.
2) Defer constraint. This is done via the SET command and affects only the current session. The constraint remain in effects for other sessions, unless they also defer it, and it gets enforced again upon commit or when setting the constrain back to IMMEDIATE. So this is what you want, at least in theory.
There are two caveats with deferred constraints: the constraint must be created as DEFERRABLE. Once created, it cannot be altered to be DEFERRABLE. So until you
drop and recreate the constraint as deferrable, you cannot defer that constraint.
Secondly, there is probably a bug in Oracle in handling deferred constraints. We noticed rows violating FK constraint in customer's database in tables which are handled with deferred mode sometimes. I tried to convince the customer's DBAs to file this with Oracle support, but they didn't. However, a web search confirmed we're not the only one who run into such an issue.
So, to wrap it up: my advice is not to update primary keys. Try to have the database model (which is seriously flawed) to be repaired.