Deadlock when executing package simultaneously from two different sessions

Question

I have written a package which will do the below tasks .
package A
Delete data which was older than one year from master table A and then populate data from stage table A to master table A .
truncate summary table and populate the summary table from the master table .
The package will be executed from a java application with the help of a scheduler in java. Some times, the packageA is still executing, while another instance of the package A is scheduled, that creating to deadlock in oracle. we can not use dbms_locks pkg in our application due to restrictions . i want to handle this situation from the db side in such way that the session B , need to wait until the session A completes the execution of the package . Can some one please tell how to handle this scenario in pl/sql?
I thought of creating a function which will return the execution status of package A by reading a flag from temporary table . So that next schedule can be scheduled with the return status of the function. is there any other way other than this , so that i can pause execution of package A in session B and resume after session A is successfully executed
create or replace pkg a
populate master ;
populate smry ;
populate app_tables ;
end pkg ;
create or replace pkg body
populate master()
delete from master where loaddate < sysdate -365;
loop
fetch from stage a
insert to master a
end loop
populate smry()
truncate sumary a ;
insert into smry
select values from master ;
populate app_tables()
populate master;
populate smry ;
end pkg body

Answer 1

I have a question about your requirements. I'm not questioning them just trying to understand them. You wrote:
Delete data which was older than one year from master table A and then populate data from stage table A to master table A .
truncate summary table and populate the summary table from the master table . If this is all there is to the requirement why would a second invocation be scheduled so soon? If you delete all data older than one year why would you need to do it again so soon?
Notwithstanding the above you basically need a serialization management process.
For all batch frameworks I have worked with we always include batch control and status tables to:
1. guarantee that batches are run in the proper order
2. allow for batch restart
3. allow for suspension or termination of single batch jobs or job streams
4. provide for reporting of batch statistics - batch run time, records processed, etc.
5. simplify the testing of complex batch streams. Tests can be performed on any one batch step or any combination of steps by enabling/disabling flags in the control tables.
6. eliminate the possibility of the problem you are reporting
Using one or more batch control and status tables, in my opiinion, is the simplest and best way to serialize the batch jobs you are dealing. Such tables gives you maximum flexibility while placing the fewest constraints on the system.
In the system I work with we try to have a clear line of demarcation between processes that control the work to be done and the processes that actually do the work.
The processes that do the work never determine what data they work with; they are parameterized so that they are told what data to use. All they know is how to process the data that they are told to process. This makes it easier to scale to add additional 'worker' processes by having the 'control' processes break up the data into different batches and running 'worker's in parallel.
I would suggest designing and implementing a control hierarchy to oversee the execution of the worker processes. This will be your serialization manager.