[
https://issues.apache.org/jira/browse/TRAFODION-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495917#comment-16495917
]
ASF GitHub Bot commented on TRAFODION-2946:
-------------------------------------------
Github user DaveBirdsall commented on a diff in the pull request:
https://github.com/apache/trafodion/pull/1586#discussion_r191957899
--- Diff: core/sql/cli/Context.cpp ---
@@ -3163,6 +3163,59 @@ Lng32 ContextCli::setSecInvalidKeys(
}
+Int32 ContextCli::checkLobLock(char *inLobLockId, NABoolean *found)
+{
+ Int32 retcode = 0;
+ *found = FALSE;
+ CliGlobals *cliGlobals = getCliGlobals();
+ StatsGlobals *statsGlobals = GetCliGlobals()->getStatsGlobals();
+ if (cliGlobals->getStatsGlobals() == NULL)
+ {
+ (diagsArea_) << DgSqlCode(-EXE_RTS_NOT_STARTED);
+ return diagsArea_.mainSQLCODE();
+ }
+ statsGlobals->checkLobLock(cliGlobals,inLobLockId);
+ if (inLobLockId != NULL)
+ *found = TRUE;
+ return retcode;
+}
+Lng32 ContextCli::setLobLock(
+ /* IN */ char *lobLockId // objID+column number
+ )
+{
+ CliGlobals *cliGlobals = getCliGlobals();
+ if (cliGlobals->getStatsGlobals() == NULL)
+ {
+ (diagsArea_) << DgSqlCode(-EXE_RTS_NOT_STARTED);
+ return diagsArea_.mainSQLCODE();
+ }
+ ComDiagsArea *tempDiagsArea = &diagsArea_;
+ tempDiagsArea->clear();
+
+ IpcServer *ssmpServer = ssmpManager_->getSsmpServer(exHeap(),
+ cliGlobals->myNodeName(),
+ cliGlobals->myCpu(), tempDiagsArea);
+ if (ssmpServer == NULL)
+ return diagsArea_.mainSQLCODE();
+
+ SsmpClientMsgStream *ssmpMsgStream = new (cliGlobals->getIpcHeap())
+ SsmpClientMsgStream((NAHeap *)cliGlobals->getIpcHeap(),
+ ssmpManager_, tempDiagsArea);
+ ssmpMsgStream->addRecipient(ssmpServer->getControlConnection());
+ LobLockRequest *llMsg =
+ new (cliGlobals->getIpcHeap()) LobLockRequest(
+ cliGlobals->getIpcHeap(),
+ lobLockId);
+ *ssmpMsgStream << *llMsg;
+ // Call send with no timeout.
+ ssmpMsgStream->send();
--- End diff --
Is this a "datagram" protocol? That is, do we wait for some acknowledgement
from the SSMP that our message was processed? Or do we just continue on? Do we
assume that we have the lock once send() completes?
> LOB : Locking/transaction support needed for LOB files for DDL and IUD
> operations
> ----------------------------------------------------------------------------------
>
> Key: TRAFODION-2946
> URL: https://issues.apache.org/jira/browse/TRAFODION-2946
> Project: Apache Trafodion
> Issue Type: New Feature
> Components: dtm, sql-general
> Affects Versions: any
> Reporter: Sandhya Sundaresan
> Assignee: Sandhya Sundaresan
> Priority: Major
> Attachments: Locking issue for concurrent access of LOBs.docx
>
>
> Trafodion DTM needs to recognize LOB HDFS data files that contain the actual
> critical data for a LOB column and treat them as part of the Trafodion object
> that contains the LOB column. The Trafodion table itself contains the LOB
> handle that can be used to derive the LOB data file name/location.
> DDL operations performed on LOB tables today only work on the Trafodion
> table. The dependent HDFS data files are not treated as part of the DDL
> transaction. ANy parallel operations or errors during create/drop will leave
> the table in an inconsistent state.
>
> DML operations on any LOB table only work on the LOB table and it's dependent
> descriptor tables that are also Trafodion tables (contain offset/length
> information in the HDFS data file for each LOB column). But the HDFS data
> file operation is not covered as part of the transaction. So any IUD error
> will leave the LOB table in an inconsistent state .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
