Ignore:
Timestamp:
2018-11-07T20:44:34+13:00 (5 years ago)
Author:
ak19
Message:

Now that previous commit(s) put sig handlers in place in gs_sql, have been able to add in Undo on build/import Cancel for the GS SQL Plugs. This utilizes AutoCommit vs Transaction (rollback/commit) behaviour. On cancel, a sig handler is triggered (SIGINT) and, if AutoCommit is off, does a rollback before die() which calls object destructor and disconnects from db. On regular program execution running to normal termination, the last finish() call on gs_sql that will trigger the disconnect, will now first do a commit(), if AutoCommit is off, before disconnecting. For now, the default for both GreenstoneSQLPlugs is to support Undo (i.e. transactions), which turns AutoCommit off. Not sure whether this will be robust: what if transactions take place in memory, we could be dealing with millions of docs of large full-txt. Another issue is that the SQL DB may be out of sync with archives and index folder on Cancel: archives and index just terminate and are in an intermediate state depending on when cancel was pressed. Whereas the GS SQL DB is in a rolled back state as if the import or build never took place. A third issue is that during buildcol (perhaps specifically during buildcol's doc processing phase), pressing Cancel still continues buildcol: the current perl process is cancelled but the next one continues, rather than terminating buildcol in entirety. What happens with the GS SQL DB is that any 'transaction' until then is rolled back, perhaps a transaction regarding one doc if the Cancel affects on a doc basis, and the next process (next doc processing?) continues and allows for further transactions that are all committed at the end on natural termination of buildcol. Need to whether Undo behavious is really what we want. But it's available now and we can simply change the default to not support Undo if we want the old behaviour again.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • main/trunk/greenstone2/perllib/plugouts/GreenstoneSQLPlugout.pm

    r32580 r32582  
    3838use DBI; # the central package for this plugout
    3939
     40
     41# This entire class is called only during import.pl
    4042
    4143# TODO: SIGTERM rollback and disconnect?
     
    6971        'desc' => "{GreenstoneSQLPlug.process_mode.all}" } ];
    7072
     73my $rollback_on_cancel_list =
     74    [ { 'name' => "true",
     75        'desc' => "{GreenstoneSQLPlug.rollback_on_cancel}" },     
     76      { 'name' => "false",
     77        'desc' => "{GreenstoneSQLPlug.rollbacl_on_cancel}" } ];
     78
    7179# The following are the saveas.options:
    7280my $arguments = [
     
    7684      'list' => $process_mode_list,
    7785      'deft' => "all",
     86      'reqd' => "no",
     87      'hiddengli' => "no"},
     88    { 'name' => "rollback_on_cancel",
     89      'desc' => "{GreenstoneSQLPlug.rollback_on_cancel}",
     90      'type' => "enum",
     91      'list' => $rollback_on_cancel_list,
     92      'deft' => "true", # TODO Q: what's the better default? If "true", any memory concerns?
    7893      'reqd' => "no",
    7994      'hiddengli' => "no"},
     
    146161    'collection_name' => $ENV{'GSDLCOLLECTION'},
    147162    'verbosity' => $self->{'verbosity'} || 0
     163   
    148164    };
    149165
    150166    my $gs_sql = new gssql($db_params);
     167
     168    # if autocommit is set, there's no rollback support
     169    my $autocommit = ($self->{'rollback_on_cancel'} eq "false") ? 1 : 0;
    151170   
    152171    # try connecting to the mysql db, die if that fails
     
    156175    'db_client_user' => $self->{'db_client_user'},
    157176    'db_client_pwd' => $self->{'db_client_pwd'},
    158     'db_host' => $self->{'db_host'}
     177    'db_host' => $self->{'db_host'},
     178    'autocommit' => $autocommit
    159179                   })
    160180    )
     
    164184    die("Could not connect to db. Can't proceed.\n");
    165185    }
     186
     187    #die("@@@@ TEST. Connected successfully. Testing gssql::destructor.\n"); # WORKS
    166188   
    167189    my $db_name = $self->{'site_name'} || "greenstone2"; # one database per GS3 site, for GS2 the db is called greenstone2
Note: See TracChangeset for help on using the changeset viewer.