Error while executing a create query through java code in documentum 6.5sp3

Hi All

I am getting an error while trying to execute a DQL statement i.e. a create query through java code. It is saying "You cannot perform 'attach' operation since there is an open transaction in this session."; ERRORCODE: 100; NEXT: null. The create query was "create "+processType+" objects set object_name='TestObject' link '/WIS/System/Blank Documents';. Here the processType is giving correct value before the query execution line of the code and the query is flawless when trying to be executed through Samson tool. I have taken a print of the query before the query execution line in my code and the printed query is working fine through samson. Here is the exact snippet below:

//Snippet below:

IDfCollection col= null;

IDfQuery query = new DfQuery();

System.out.println("create "+processType+" objects set object_name='TestObject' link '/WIS/System/Blank Documents';");

query.setDQL("create "+processType+" objects set object_name='TestObject' link '/WIS/System/Blank Documents';");

try {

System.out.println("getDfSession()+++++++++"+getDfSession());

System.out.println("getDfSession().isConnected()+++++++++"+getDfSession().isConnected());

col=query.execute(getDfSession(), 1);

if(col!=null){

while(col.next()){

strBlankDocumentId= col.getString("object_created");

}

}catch(Exception e){

e.printStackTrace();

}finally{

if(col!=null){

col.close();

}

//Snippet above

Please find the exact error below which is given in the stdout log for the above red line snippet:

DfException:: THREAD: http-8080-1; MSG: [DM_API_E_CANT_WITH_OPEN_TRAN]error: "You cannot perform 'attach' operation since there is an open transaction in this session."; ERRORCODE: 100; NEXT: null
     at com.documentum.fc.common.DfException.newCantWithOpenTranException(DfException.java:134)
     at com.documentum.fc.client.DfSysObject.verifyPolicyChangeAllowed(DfSysObject.java:2333)
     at com.documentum.fc.client.DfSysObject.doAttachPolicy(DfSysObject.java:2364)
     at com.documentum.fc.client.DfSysObject.attachPolicy(DfSysObject.java:2340)
     at com.citibank.tbo.ctbautoapp.CtbAutoApp___PROXY.attachPolicy(CtbAutoApp___PROXY.java)
     at com.citibank.tbo.ctbdocument.CtbDocument.attachLifeCycle(CtbDocument.java:87)
     at com.citibank.tbo.ctbautoapp.CtbAutoApp.attach(CtbAutoApp.java:236)
     at com.citibank.tbo.ctbautoapp.CtbAutoApp.doSave(CtbAutoApp.java:218)
     at com.documentum.fc.client.DfPersistentObject.saveEx(DfPersistentObject.java:899)
     at com.documentum.fc.client.DfPersistentObject.save(DfPersistentObject.java:894)
     at com.citibank.tbo.ctbautoapp.CtbAutoApp___PROXY.save(CtbAutoApp___PROXY.java)
     at com.documentum.fc.client.impl.dql.DqlUpdate.processCreate(DqlUpdate.java:629)
     at com.documentum.fc.client.DfQuery.runQuery(DfQuery.java:187)
     at com.documentum.fc.client.DfQuery.execute(DfQuery.java:216)
     at com.citibank.manualUpload.ManualUpload.getBlankItemId(ManualUpload.java:870)
     at com.citibank.manualUpload.ManualUpload.getBlankDocumentId(ManualUpload.java:821)
     at com.citibank.manualUpload.ManualUpload.populateAppInfo(ManualUpload.java:796)
     at com.citibank.manualUpload.ManualUpload.gotoPage(ManualUpload.java:728)
     at com.citibank.manualUpload.ManualUpload.onNext(ManualUpload.java:573)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.documentum.web.form.FormProcessor.invokeMethod(FormProcessor.java:1633)
     at com.documentum.web.form.FormProcessor.invokeMethod(FormProcessor.java:1487)
     at com.documentum.web.form.FormProcessor.fireActionEvent(FormProcessor.java:1303)
     at com.documentum.web.form.RecallOperation.execute(RecallOperation.java:101)
     at com.documentum.web.form.FormProcessor.processAction(FormProcessor.java:113)
     at com.documentum.web.form.FormAction.processAction(FormAction.java:107)
     at com.documentum.web.env.WDKController.doStartRequest(WDKController.java:191)
     at com.documentum.web.env.WDKController.processRequest(WDKController.java:92)
     at com.documentum.web.env.WDKController.doFilter(WDKController.java:83)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
     at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:837)
     at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
     at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1287)
     at java.lang.Thread.run(Unknown Source)

NB: The same code was working fine in 5.3 environment. But recently I am getting this error in 6.5 environment.

Please tell me what can be the solution for the same. Looking for urgent reply.

Thanks in advance

Dctm_Dev

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

Jubedus

Hi dctm_dev,
If I understand correctly you want to create an object using DQL in order to bypass the logic in the TBO. This approach worked fine in 5.3 because DQL queries didn’t trigger TBO methods. However, this behavior was changed in DFC 6.5. All DQL queries executed with DFC 6.5 are going through TBOs. Every time a new object is created either using DQL or DFC methods the appropriate TBO methods will be called. In your case, method doSave of the class com.citibank.tbo.ctbautoapp.CtbAutoApp is executed.
You may consider it a problem in DFC. But it’s actually an improvement. The purpose of the TBO is to enforce business rules no matter how the object is created or updated. DFC 6.5 guarantees this functionality.
I’d suggest resolving the problem in the custom TBO. It may be easy to fix. The problem can be determined if you put the source code of the following methods here
    com.citibank.tbo.ctbdocument.CtbDocument.attachLifeCycle
    com.citibank.tbo.ctbautoapp.CtbAutoApp.attach
    com.citibank.tbo.ctbautoapp.CtbAutoApp.doSave

If you don’t want to modify TBOs then you may try creating the object using API. But I wouldn’t recommend this approach.

Good luck!

All comments

Jubedus

Hi dctm_dev,

You are right about the query. The query looks fine and I’m not surprised it works without problems when executed from Samson.

The error seems to be caused by the custom Type-based Business Object (TBO). If you look at the Java stack trace then you’ll notice a reference to the custom class com.citibank.tbo.ctbautoapp.CtbAutoApp. Most likely, this is the TBO implementation class for the custom type (value of processType) that you use in your query.

Based on the error message, the TBO tries to attach the document to a lifecycle on save. The error states that there is already an open transaction. The error message matches with the comment in the DFC Javadocs for the method IDfSysObject#attachPolicy. According to the comment, this method cannot be used “in a user-defined transaction”. Probably, a transaction is opened explicitly in the TBO before attaching the document to a lifecycle.

Samson does not use DFC. All queries executed from Samson bypass the Business Objects Framework (BOF), which means TBOs are not executed. That’s why you’re able to execute the query successfully from Samson. I suppose it’s one of the reasons Samson is no longer provided by EMC.

I hope it helps. Good luck!

dctm_dev

Hi Andrei,

Thanks for d reply. Yes you are right that there is a TBO for the custom object type. But here we are not doing save operation. As a result the code snippet was working fine without any issue in 5.3 environment. TBO was there too. Suddenly after migration is done from 5.3 to 6.5 it has been stopped working. And for your information we are not creating a new object and saving it due to the tbo obstacle here. That is the only reason we are trying execute a create query through java code and it was working fine in 5.3 environment and even in 6.5 environment too somedays before when the code change is not done. But it has been stopped working now after we have changed our project codebase and made it compatible to 6.5. But now I am unable to find what might be the reason of it. If you have any idea then please come with that.

Thanks in advance

dctm_dev

Hi Andrei,

Even I dont want the execution of the TBO when creating the object. That is why I did not use the new object creation and save operation. That was moto from 5.3 environment and it was working fine in that environment and in 6.5 environment earlier the code change. There were TBO but the effect of the TBO was not in picture while we are creating the object thorugh query.

Thanks

dctm_dev

Jubedus

If you don’t want to modify TBOs then you may try creating the object using API. But I wouldn’t recommend this approach.

Good luck!

mpraditt

Hi there!

I see great information here!! Thanks so much for posting -- I'm going to move this over to the Documentum Community on EDN. Hoping for more developers will weigh in and appreciate this!

Thanks!

-Manni