40
Points
Questions
9
Answers
4
-
The Transaction Manager does not work for us either. This is the error we receive when calling begin().
java.lang.ClassCastException: weblogic.transaction.internal.ClientTransactionManagerImpl cannot be cast to javax.transaction.UserTransaction
This makes certain things impossible to do, such as trying to remove an Item which could be on another Item’s BOM, while it also has a Relationship. If we remove the relationships first, and it fails because of it being a child on a BOM, the relationships are gone. However, if we try to soft delete it first, it fails because it has relationships. There’s no way to create a Rollback Transaction with the SDK right now.
Edit:
Apparently that class is not automatically transferred from the API ClassLoader. However, Transaction Management appears to not work at all. Beginning a Transaction, Modifying an Object, and then Rolling back the transaction does not undo the change. Any ideas?
- 1774 views
- 3 answers
- 0 votes
-
- 2328 views
- 3 answers
- 0 votes
-
@furqantariq1992 Despite what the documentation says about the Agile PLM API being thread-safe, it is not. It fails if it attempts to make two sequential calls to the server at the same time. This is why the documentation says multi-threaded applications must “`syncrhonize“` calls to a IAgileSession. You can fix these errors by ensuring that your calls to IAgileSession are never made at the same time. However, this also means there isn’t much point in making multiple threads with a single IAgileSession. And because the product limits the number of open IAgileSession’s with the same User, the API is even less “thread-capable.”
I know it has been two years since you’ve asked, but this question is the first one when users search for this error and I wanted others to understand what is happening.
- 2605 views
- 2 answers
- 1 votes
-
@bhaskarap1 We see this happening if your or someone else have PLM open and is looking at the Object in question. It appears that Agile PLM does not put locks on Item’s themselves, but on the Table’s which are associated with each Item. Thus, only a single Session can Read OR Write a Table (Attachments, Relationships, etc.) of an Item at one time. There could be a timing issue with your PX, thus you may want to implement a Retry mechanism for obtaining the Table on the Item. You can check to see if the error is a Concurrent Modification error, and do backoff waiting, try again, and loop that a few times. It seems quite effective as there is nothing in the API to be notified when the Item is no longer locked.
Personally, I find the entire Pessimistic Locking of Items even for Read to be slightly less than impossible to work with. I have never come across a product which locks objects for read without providing any way to release those locks. One has to destroy the Session in which the Table was read in order to release the lock.
Good luck!
- 2681 views
- 3 answers
- 0 votes