The "problem" is caused because applying a lifecycle is done on the Java Method Server in a separate session (invoked as a method). So you must save your sysobject (in the doSave method call the super.doSave()) and after that you can call the attach method to apply a lifecycle.
This means you cannot even do a transaction on the whole process because these two sessions are separated (one is running as a "client"/as a web application/webtop and another is running on the server).
A code example would be nice to be sure, but the essence of my message is still the same: you must not have any "uncommited" modifications before you apply the lifecycle (call attach method). And after that if you intend to do anything with your sysobject (which in the meantime got it's lifecycle), you must refetch it to get the fresh one (as it is changed in meantime on the server, and your "client side code" is not aware of it).
You shouldn't call sysObj.save(); on line 110, as sysObj.attachPolicy() does it implicitly for you.
That's why you got this exception (your local copy of the sysobject is out of date)
And some helpful hints:
- Put your Java class in a package
- Call super.doSave(saveLock,versionLabel,extendedArgs); in the doSave, otherwise your object won't get saved ever.
- It is not nice to query the database tables directly (_s and _r tables), you should get the information through objects or through more queries.
- Always put the collection.close() in a finally block, even if you don't need to catch the exception (try ... finally)
- If you need to get only the r_object_id, then query only that (line 102), it's far more faster and efficient
- If your TBO's interface is ITestTBO then it's recommended to name the implementation class as TestTBO.
true, not good to query on base tables but for some jobs like getting the folder path of objects there might be no other way!
but I do have a problem with "System.out.println"... There are many well documented reasons to not use System.out.println and replace it with a Logger. Documentum has wrapped Logger in DfLogger.... very powerful and useful when you finally figure it out.
As for the save issue... attaching a lifecycle does require the java method server, hence you will get version miss matches. After attaching the policy, refetch the object using "fetch()" or by "(IDfSysObject)session.getObjectByPath(path+"/"+obj);"
To apply a lifecycle first you must save the sysobject, or you can call sysObj.fetch() but I belive you will lose changes.
If you save it first, applying the maybe LC could throw an exception which will produce an awkward situation - a saved object with no LC.
I you use a transaction it won't work.
You can set up a server method that will apply the LC but you should call it async - but this can also produce an awkward situation if the method is not yet executed before some other process changes the sysobject.
What I would do is to change the ACL so only superuser can see it. Then link it to the destination folder and save and then call a server method asynchronuosly that will apply a lifecycle and chang ACL back, or maybe set up a job for that.