That's not something you are going to be able to do. Nested transactions means that. The second transaction is nested within the first transaction. The second transaction can be commited and processing after that can take advantage of any changes done within the second transaction but that transaction can still be rolled back if the first transaction is rolled back even if has already been commited.

You might want to think about the design here. If the second transaction can exist on its own, then perhaps you can make it the first transaction, commit it and end the transaction. Do you need information from the first series of updates to perform the new ID processing? If no, get a new ID at the beginning of the process and never look back. If you do need to discard the updates by rolling back , then you only need to discard the ID generated at the top. In most cases, this isn't a big deal, YMMV.

>Thanks for reply.still i think this will not work for me. let me explain you my requirements. what i want is when i issue commit for second level transaction it should commit the changes permanently and free second level's resources.
>what's happening right now is until first level transaction is not committed it neither free second level's resources nor commit second level's changes permanently.
>
>I am getting new id in second level which i want to committ as soon as its done. so other network users can access the table. so at second level i want a transaction that is independant of other active transaction.
>is it possible? please let me know.
>
>Thanks
>Mark