You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/06/01 07:39:00 UTC

[jira] [Commented] (TRAFODION-2946) LOB : Locking/transaction support needed for LOB files for DDL and IUD operations

    [ https://issues.apache.org/jira/browse/TRAFODION-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16497687#comment-16497687 ] 

ASF GitHub Bot commented on TRAFODION-2946:
-------------------------------------------

Github user sandhyasun commented on a diff in the pull request:

    https://github.com/apache/trafodion/pull/1586#discussion_r192318454
  
    --- Diff: core/sql/runtimestats/sscpipc.cpp ---
    @@ -907,3 +910,53 @@ void SscpNewIncomingConnectionStream::processSecInvReq()
       request->decrRefCount();
     }
     
    +void SscpNewIncomingConnectionStream::processLobLockReq()
    +{
    +  IpcMessageObjVersion msgVer = getNextObjVersion();
    +
    +  ex_assert(msgVer <= currRtsStatsReqVersionNumber, "Up-rev message received.");
    +  NAHeap *statsHeap = NULL;
    +  LobLockRequest *request = new(getHeap())
    +    LobLockRequest(getHeap());
    +
    +  *this >> *request;
    +  ex_assert( !moreObjects(), "unknown object follows LobLockRequest.");
    +  SscpGlobals *sscpGlobals = getSscpGlobals();
    +  StatsGlobals *statsGlobals = sscpGlobals->getStatsGlobals();
    +  int error = statsGlobals->getStatsSemaphore(sscpGlobals->getSemId(),
    +                  sscpGlobals->myPin());
    +  statsHeap = statsGlobals->getStatsHeap();
    +  char *ll = new (statsHeap) char [LOB_LOCK_ID_SIZE];
    +  memcpy(ll,request->getLobLockId(),LOB_LOCK_ID_SIZE+1);
    +  SyncHashQueue *lobLockList = statsGlobals->getLobLocks();
    +  if (ll[0] == '+') // If it's a positive value, we are supposed to insert it.
    --- End diff --
    
    To address the scenario where 2 clients on different nodes check for a lock and being the process of setting it, instead of simply setting/inserting into the HashQueue, we should do an extra check for existence here before setting . If it's already there, some other process on another node may have propagated the same lockLockId first . So we should send a diagsArea back here to indicate the set  for this client/process failed. 


> 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)