System.Data.SQLite
Check-in [45cc5a21fa]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Update a statement in the provider limitations documentation regarding deferred transaction locking semantics. Fix for [425f060dec].
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 45cc5a21fa9a4337b19b5bf607c5f8c4618d2617
User & Date: mistachkin 2014-07-02 17:45:06
References
2014-07-02
17:46 Closed ticket [425f060dec]: Documentation update - "Limitations of ..." plus 4 other changes artifact: 624c6b5775 user: mistachkin
Context
2014-07-18
22:04
Add initial performance tests for the SQLiteDataReader class. check-in: d3be3b1abe user: mistachkin tags: trunk
2014-07-02
17:45
Update a statement in the provider limitations documentation regarding deferred transaction locking semantics. Fix for [425f060dec]. check-in: 45cc5a21fa user: mistachkin tags: trunk
2014-06-23
22:55
Final updates for the 1.0.93.0 release. check-in: 47ba62f72c user: mistachkin tags: trunk, release, release-1.0.93.0
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to Doc/Extra/Provider/limitations.html.

    39     39             </td>
    40     40           </tr>
    41     41         </table>
    42     42       </div>
    43     43       <div id="mainSection">
    44     44       <div id="mainBody">
    45     45         <h1 class="heading">Limitations of this ADO.NET SQLite Data Provider</h1>
    46         -      <p>As providers go, this one doesn't have many restrictions. SQLite has no 
    47         -        support for row-level or table-level locks. When a connection locks the database for writing, no other connection or process may read or write to the database until the write operation is complete.  The SQLite.NET provider attempts to retry 
    48         -        internally if a database is locked, up to the CommandTimeout property of the 
           46  +      <p>As providers go, this one doesn't have many restrictions. SQLite has no
           47  +        support for row-level or table-level locks. When a connection locks the database for writing, no other connection or process may read or write to the database until the write operation is complete.  The SQLite.NET provider attempts to retry
           48  +        internally if a database is locked, up to the CommandTimeout property of the
    49     49           command in question.</p>
    50         -      <p>SQLite is inherently type-less, and only understands a few basic datatypes 
    51         -        natively. They are (in .NET-speak) Int64, Double, String and Blob. The 
    52         -        SQLite.NET provider will use the database schema information it can glean to 
           50  +      <p>SQLite is inherently type-less, and only understands a few basic datatypes
           51  +        natively. They are (in .NET-speak) Int64, Double, String and Blob. The
           52  +        SQLite.NET provider will use the database schema information it can glean to
    53     53           enforce type-ness, but it is an inexact science.</p>
    54     54         <p>
    55         -        Hierarchical DataReaders are not supported. In the 
    56         -        case of transactions, any SQLiteCommand created on a connection will (when 
    57         -        executed) automatically join a transaction in progress, regardless of whether 
           55  +        Hierarchical DataReaders are not supported. In the
           56  +        case of transactions, any SQLiteCommand created on a connection will (when
           57  +        executed) automatically join a transaction in progress, regardless of whether
    58     58           that transaction was created before or after the command.</p>
    59         -      <p>A SQLiteCommand object <b>can</b> be re-assigned a new SQLiteConnection object 
           59  +      <p>A SQLiteCommand object <b>can</b> be re-assigned a new SQLiteConnection object
    60     60           as long as no DataReaders are active on the command.</p>
    61         -      <p>Opening a transaction is considered a write operation, so only use them when 
    62         -        you want to write to the database! If you hold open a transaction, all readers on other
    63         -        connections
    64         -        will be blocked until the transaction is closed!</p>
           61  +      <p>Opening a transaction is considered a write operation, so only use them when
           62  +        you want to write to the database! If you hold open an &quot;immediate&quot;
           63  +        transaction, all readers on other connections will be blocked until the
           64  +        transaction is closed!</p>
    65     65         <p></p>
    66     66         <h4 class="subHeading">Thread Safety</h4>
    67     67         <p>Multi-threading in SQLite must be done carefully. Here are the restrictions:</p>
    68     68         <ul>
    69     69           <li>
    70     70             <b>You May</b>
    71         -        Clone() a SQLiteConnection object in one thread and pass the cloned object to 
    72         -        another thread. Once passed, the other thread becomes the new owner of the 
    73         -        cloned connection, and the original thread must not keep a reference to the 
           71  +        Clone() a SQLiteConnection object in one thread and pass the cloned object to
           72  +        another thread. Once passed, the other thread becomes the new owner of the
           73  +        cloned connection, and the original thread must not keep a reference to the
    74     74           clone or call any methods on the clone.
    75     75           <LI>
    76     76             <STRONG>You May</STRONG>
    77         -        create multiple threads, and those threads can create their own 
    78         -        SQLiteConnection and subsequent objects for accessing a database.&nbsp; 
    79         -        Multiple connections on multiple threads to the same database file are 
           77  +        create multiple threads, and those threads can create their own
           78  +        SQLiteConnection and subsequent objects for accessing a database.&nbsp;
           79  +        Multiple connections on multiple threads to the same database file are
    80     80           perfectly&nbsp;acceptable&nbsp;and will behave predictably.&nbsp;
    81     81           <li>
    82     82             <b>You May NOT</b>
    83         -        call methods or properties or otherwise reference any SQLite provider classes 
           83  +        call methods or properties or otherwise reference any SQLite provider classes
    84     84           that belong to another thread.
    85     85           <li>
    86         -          <b>You May NOT</b> pass a SQLiteCommand, SQLiteDataReader, SQLiteDataAdapter or 
    87         -          any other SQLite provider class except a cloned SQLiteConnection to another 
           86  +          <b>You May NOT</b> pass a SQLiteCommand, SQLiteDataReader, SQLiteDataAdapter or
           87  +          any other SQLite provider class except a cloned SQLiteConnection to another
    88     88             thread.</li>
    89     89         </ul>
    90         -      <p>Understand again that SQLite has no fine-grained locking mechanisms. It is 
    91         -        therefore your own responsibility in a multi-threaded environment to handle 
    92         -        potential timeouts that may occur if a long-running query in one thread 
    93         -        prevents a query in another thread from executing. These timeouts will only 
    94         -        occur if one thread is attempting to read while another thread is attempting to 
    95         -        write. Whichever thread got its lock first will be the one to execute, and the 
    96         -        other thread will block until the CommandTimeout value elapses or the other 
           90  +      <p>Understand again that SQLite has no fine-grained locking mechanisms. It is
           91  +        therefore your own responsibility in a multi-threaded environment to handle
           92  +        potential timeouts that may occur if a long-running query in one thread
           93  +        prevents a query in another thread from executing. These timeouts will only
           94  +        occur if one thread is attempting to read while another thread is attempting to
           95  +        write. Whichever thread got its lock first will be the one to execute, and the
           96  +        other thread will block until the CommandTimeout value elapses or the other
    97     97           thread finishes.</p>
    98     98         <hr/>
    99     99         <div id="footer">
   100    100           <p>
   101    101             <a href="mailto:sqlite-users@sqlite.org?subject=SQLite.NET%20Class%20Library%20Documentation%20Feedback:%20Limitations">
   102    102               Send comments on this topic.</a>
   103    103           </p>