---

acad.JPG

Hallo zusammen,
ich versuche einen WF zu starten, bekomme aber eine Fehlermeldung (siehe Anhang), dass die Itemrevision von einem anderen bestimmten Kollegen gesperrt ist! Die Itemrevision und ihre Datasets sind aber eingecheckt, und der Kollege meinte, dass er aktuell die Revision nicht benutzt!
Hat einer von Euch eine Idee, woran das liegt!
Vielen Dank 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

- ein "clearlocks -verbose" absetzen ( kann aber andere negative Auswirkungen haben ... )
- alternativ dazu als DBA User die aktuellen User anzeigen lassen und wenn danach gefragt wird, abgelaufene Sitzungen bereinigen lassen.
- Vielleicht versuchen die ItemRevision ( und Datasets ? ) zu purgen ("bereinigen") ?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Thomas,
Danke für deine Antwort.
Ich habe versucht die Itemrevision und die Datasets zu "bereinigen". Das hat aber nicht geholfen!
Danach habe ich den Kollegen gefragt, TC abzumelden und seinen Rechner neu zu starten und jetzt ist die Itemrevision nicht mehr von ihm gesperrt! 
Was kann aber die Ursache sein?, da wie gesagt, die Itemrevision nicht ausgecheckt war!
Danke

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo TCatMB,

das Problem habe ich auch gelegentlich und ich sage es gleich, keine vernünftige Lösung gefunden. Vor allem wenn ich als dba an Daten „herumgeschraubt“ klagen meine Kollegen, dass die entsprechenden Daten vom dba am Knoten gesperrt sind. Meine Lösung ist auch nur abmelden, sehr nervig.
Also, wenn jemand noch ne Lösungsvorschlag hätte, wir würden ihn gerne ausprobieren.

Gruß an alle und noch ein gute neues Jahr …… soviel Zeit muss sein 

Lupone

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Lupone,
unsere Vermutung, dass die Verbindung Client-Server getrennt wurde, so entsteht die sog. "dead session with locked nodes".
Um diese gesperrten Konten zu befreien, hat es immer funktioniert, TC neu zu starten. Ich glaube aber nicht, dass diese Aktion die tote Sitzung bereinigt!!
Letztendlich haben wir uns beschlossen, "clearlocks -verbose" täglich auszuführen, ich weiß aber nicht, was die negativen Auswirkungen, die ThomasZwatz erwähnt hat, sein können. 
Gruß
 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von ThomasZwatz:
- ein "clearlocks -verbose" absetzen ( kann aber andere negative Auswirkungen haben ... )
...

---

Ab einschliesslich TC 8.3 ist es angeblich nicht mehr "Good Practise" häufig ein "clearlocks -verbose" laufen zu lassen.
Auch GTAC sieht das so.

Ich beziehe mich u.a. auf diesen Beitrag: http://siomsystems.com/clearlocks-enhancements/
Und mache inzwischen nur mehr 1x täglich ein "clearlocks -verbose"
( Obwohl ich selbst keinerlei negative Erfahrungen damit in TC 8.3 gemacht habe - vorher hab ichs stündlich laufen lassen ).

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

In TC 9.1 gibt es wiederum einen Bug, der es nötig macht "clearlocks" wesentlich öfter auszuführen (Also so schlimm kann "clearlocks" dann doch nicht sein ;-)
Ich lasss Clearlocks immer früh vor Arbeitsbeginn und in der Mittagspause laufen. Bis jetzt keine Probleme. Auch nicht bei einem reconnect nach der Mittagspause.:

R #:
1920889
Date:
Dec-13-2012

CURRENT WORKAROUND
==================
Run "clearlocks -verbose" on a regular basis, or at least at times of known drops in the server Manager PROCESS_TARGET value.

ADDITIONAL DATA PROVIDED: (Y/N)
===============================
Uploaded to PR_DATA is the file IR1920889.zip which contains the file IR1920889.pdf.

The document IR1920889.pdf includes the customers uploaded screen grabs and also describes in more detail, how to reproduce the issue reported by the customer.

ADDITIONAL INFORMATION:
======================= 
The customer has experienced situations with their "ready for production" test system, whereby many thousands of these dead processes can occur over a period of days, due to the configured PROCESS_TARGET variations and the feeling is that when it gets to this stage it can also effect other Teamcenter activities.

The anticipated user count for this customer is in excess of 10K and hence the "ready for production" testing has highlighted this scenario due to the large variations of PROCESS_TARGET being tested. The anticipation is that this effect will diminish somewhat when tcserver processes get assigned to users during production usage, but the current behaviour is still considered incorrect.

Solution

Siemens PLM believes that the problem you reported, where warm tcserver processes that were killed due to a dynamic Server Manager PROCESS_TARGET decrement, were not clearing Teamcenter database connections, will be resolved by code changes made to the upcoming release of our Teamcenter software release 10.1.0

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP