Job is been accessed by another user
Moderators: chulett, rschirm, roy
Job is been accessed by another user
Hi All,
I am getting the following error when trying to access a Job.
Problem Desc :
I have created a Job "Testjob" and been using since 3 days. I have been designing various transformations and able to work.
When i tried to access today, I am not able to access the Job.
Instead, I am getting the following error message :
"Job TestJob is been accessed by another user".
Can anyone suggest me what is the problem and what went wrong.
As for as my knowledge, No other user is accessing the Job.
Thanks,
I am getting the following error when trying to access a Job.
Problem Desc :
I have created a Job "Testjob" and been using since 3 days. I have been designing various transformations and able to work.
When i tried to access today, I am not able to access the Job.
Instead, I am getting the following error message :
"Job TestJob is been accessed by another user".
Can anyone suggest me what is the problem and what went wrong.
As for as my knowledge, No other user is accessing the Job.
Thanks,
Antonio D'souza
If this is on Windows plataform,
Antojj, you should talk with your DS administrator and if you have admin rights you should be able to close the sesion from Director/Cleanup Resources or Admin/commands/DS.TOOLS; but you need to be carfully because you can kill some other things.
Use the forum search utility to find more detail on how to unlock a job.
good luck,
won't help.ps -ef | grep phan
kill -9 each phantom
Antojj, you should talk with your DS administrator and if you have admin rights you should be able to close the sesion from Director/Cleanup Resources or Admin/commands/DS.TOOLS; but you need to be carfully because you can kill some other things.
Use the forum search utility to find more detail on how to unlock a job.
good luck,
ak77,
if you used kill -9 then you are guaranteed to leave locks on jobs and other objects open. Even experienced people have trouble locating those locks on busy systems using LIST.READU or the client cleanup tools. Your best bet for the future is to ensure that the deadlock daemon is up and running, so the longest you will have to wait is the default 15 minutes (which you can decrease). Avoid doing a kill -9 at all costs.
if you used kill -9 then you are guaranteed to leave locks on jobs and other objects open. Even experienced people have trouble locating those locks on busy systems using LIST.READU or the client cleanup tools. Your best bet for the future is to ensure that the deadlock daemon is up and running, so the longest you will have to wait is the default 15 minutes (which you can decrease). Avoid doing a kill -9 at all costs.
Jobs will get and hold certain locks; but I don't think that a metadata table definition gets locked by a job when it uses it.
A normal kill signal is an interruptable one so that allows a process that gets this notification to cleanup up after itself. A kill -9 signal say "abort right now" and does not allow time for the process to close files correctly and release locks. A kill -9 should only be used as a last resort, such as if the normal kill modes haven't worked after a couple of minutes, and even then it should be clear that some locks will remain. The easiest solution is to let the deadlock daemon take care of these.
A normal kill signal is an interruptable one so that allows a process that gets this notification to cleanup up after itself. A kill -9 signal say "abort right now" and does not allow time for the process to close files correctly and release locks. A kill -9 should only be used as a last resort, such as if the normal kill modes haven't worked after a couple of minutes, and even then it should be clear that some locks will remain. The easiest solution is to let the deadlock daemon take care of these.