From f5c682f6ef87231ae358f233d16aeba640cfd0c6 Mon Sep 17 00:00:00 2001
From: Dimitar Misev <misev@rasdaman.com>
Date: Sun, 2 Dec 2018 18:50:27 +0100
Subject: [PATCH] ticket:1215 - fix thread-safety in rasodmg
---
08_dev-guide-cpp.rst | 58 +++++++++++++++++++++++++-------------------
1 file changed, 33 insertions(+), 25 deletions(-)
diff --git a/08_dev-guide-cpp.rst b/08_dev-guide-cpp.rst
index c59cf10..76c8082 100644
|
a
|
b
|
access is concerned):
|
| 105 | 105 | other data like images or image sets :: |
| 106 | 106 | |
| 107 | 107 | r_Database database; |
| 108 | | r_Transaction transaction; |
| | 108 | r_Transaction transaction{&database}; |
| 109 | 109 | |
| 110 | 110 | - Set the server name using the default port 7001. :: |
| 111 | 111 | |
| … |
… |
zero, and the second one by way of some assumed initialization function.
|
| 160 | 160 | :: |
| 161 | 161 | |
| 162 | 162 | r_Database database; |
| 163 | | r_Transaction transaction; |
| | 163 | r_Transaction transaction{&database}; |
| 164 | 164 | r_Minterval domain; |
| 165 | 165 | r_Ref< r_Marray<r_ULong> > image; |
| 166 | 166 | r_Ref< r_Set< r_Ref< r_Marray<r_ULong> > > > image_set; |
| … |
… |
zero, and the second one by way of some assumed initialization function.
|
| 192 | 192 | :: |
| 193 | 193 | |
| 194 | 194 | image_set = new( &database, "ULongSet" ) |
| 195 | | r_Set< r_Ref< r_Marray<r_ULong> > >; |
| | 195 | r_Set< r_Ref< r_Marray<r_ULong> > >(&transaction); |
| 196 | 196 | |
| 197 | 197 | (6) To give a name to the set for later retrieval, a ``set_object_name`` |
| 198 | 198 | message is sent to the database object. :: |
| … |
… |
zero, and the second one by way of some assumed initialization function.
|
| 220 | 220 | :: |
| 221 | 221 | |
| 222 | 222 | image = new( &database, "ULongImage" ) |
| 223 | | r_Marray<r_ULong>( domain, 0ul ); |
| | 223 | r_Marray<r_ULong>( domain, 0ul, &transaction ); |
| 224 | 224 | |
| 225 | 225 | (9) The image created in (7) is now inserted into the set. From now on, |
| 226 | 226 | the persistent object is accessible via the collection. :: |
| … |
… |
zero, and the second one by way of some assumed initialization function.
|
| 238 | 238 | :: |
| 239 | 239 | |
| 240 | 240 | image = new( &database, "ULongImage" ) |
| 241 | | r_Marray<r_ULong>( domain, &initWithCoordinates ); |
| | 241 | r_Marray<r_ULong>( domain, &initWithCoordinates, &transaction ); |
| 242 | 242 | |
| 243 | 243 | (11) The image created in (9) is inserted into the set. |
| 244 | 244 | |
| … |
… |
elements and iteration through the retrieved result set using raslib.
|
| 286 | 286 | :: |
| 287 | 287 | |
| 288 | 288 | r_Database database; |
| 289 | | r_Transaction transaction; |
| | 289 | r_Transaction transaction{&database}; |
| 290 | 290 | r_Ref< r_Set< r_Ref< r_GMarray > > > image_set; |
| 291 | 291 | r_Ref< r_GMarray > image; |
| 292 | 292 | r_Iterator< r_Ref< r_GMarray > > iter; |
| … |
… |
the raslib classes:
|
| 358 | 358 | r_ULong threshold_value = 10; |
| 359 | 359 | |
| 360 | 360 | r_Database database; |
| 361 | | r_Transaction transaction; |
| | 361 | r_Transaction transaction{&database}; |
| 362 | 362 | r_Set< r_Ref< r_GMarray > > image_set; |
| 363 | 363 | r_Ref< r_GMarray > image; |
| 364 | 364 | r_Iterator< r_Ref< r_GMarray > > iter; |
| … |
… |
the raslib classes:
|
| 408 | 408 | |
| 409 | 409 | :: |
| 410 | 410 | |
| 411 | | r_oql_execute( query, image_set ); |
| | 411 | r_oql_execute( query, image_set, &transaction ); |
| 412 | 412 | iter = image_set.create_iterator(); |
| 413 | 413 | for( iter.reset(); iter.not_done(); iter++ ) |
| 414 | 414 | { |
| … |
… |
The template class ``r_Marray<T>`` represents an MDD object over cell type
|
| 618 | 618 | ``T``. Class ``r_GMarray`` is more generic in that it is able to represent MDD |
| 619 | 619 | objects of any base type. This is necessary, firstly, for having a |
| 620 | 620 | generic class for query results where the base type is not known at |
| 621 | | compile time and, secondly, for usage in the API where the final base |
| 622 | | types are not known in advance either. |
| | 621 | compile time and, secondly, for composite (multi-band) types. |
| 623 | 622 | |
| 624 | 623 | The template class ``r_Marray<T>`` for specific base types inherits from |
| 625 | 624 | ``r_GMarray``; the constructor ``r_Marray<T>( r_GMarray& )`` is provided for |
| … |
… |
Class ``r_Transaction``
|
| 750 | 749 | ----------------------- |
| 751 | 750 | |
| 752 | 751 | To use a transaction, an object of type ``r_Transaction`` has to be |
| 753 | | inÂstantiated. Transactions can be started either in read/write or |
| | 752 | inÂstantiated with an ``r_Database`` object as an argument. |
| | 753 | Transactions can be started either in read/write or |
| 754 | 754 | read-only mode, committed, aborted, and checkpointed. It is important to |
| 755 | 755 | note that all access, creation, modification, and deletion of persistent |
| 756 | 756 | objects must be done within a transaction. In order to achieve maximal |
| 757 | 757 | performance, read-only transactions should be used whenÂever possible, |
| 758 | 758 | i.e., when no update operations occur within this transÂaction. Right |
| 759 | | now, only one transaction can be active at a time and no checkpointing |
| 760 | | is supported. |
| | 759 | now checkpointing is not supported. |
| 761 | 760 | |
| 762 | 761 | :: |
| 763 | 762 | |
| … |
… |
memory yet, it is retrieved from the server.
|
| 780 | 779 | The class ``r_Ref_Any`` is defined to support a reference to any type. Its |
| 781 | 780 | primary purpose is to handle generic references and allow conversions of |
| 782 | 781 | ``r_Ref<T>`` in the type hierarchy. A ``r_Ref_Any`` object can be used as an |
| 783 | | intermediary between any two types ``r_Ref<X>`` and ``r_Ref<Y>`` where ``X`` and ``Y`` |
| 784 | | are different types. A ``r_Ref<T>`` can always be converted to a |
| | 782 | intermediary between any two types ``r_Ref<X>`` and ``r_Ref<Y>`` where ``X`` |
| | 783 | and ``Y`` are different types. A ``r_Ref<T>`` can always be converted to a |
| 785 | 784 | ``r_Ref_Any``; there is a function to perform the conversion in the |
| 786 | 785 | ``r_Ref<T>`` template. Each ``r_Ref<T>`` class has a constructor and |
| 787 | 786 | assignment operator that takes a reference to a ``r_Ref_Any``. |
| … |
… |
and so on. If any of the ``$i`` is not followed by a parameter at the point
|
| 817 | 816 | |
| 818 | 817 | A query is executed against an open database through invocation of the |
| 819 | 818 | freestanding function ``r_oql_execute()``. This overloaded function exists |
| 820 | | in three variants: |
| | 819 | in four variants: |
| 821 | 820 | |
| 822 | 821 | :: |
| 823 | 822 | |
| 824 | | void r_oql_execute( r_OQL_Query & query ) |
| | 823 | void r_oql_execute( r_OQL_Query & query, |
| | 824 | r_Transaction* transaction ) |
| 825 | 825 | |
| 826 | | void r_oql_execute( r_OQL_Query & query, r_Set<r_Ref<r_GMarray>> & result_set ) |
| | 826 | void r_oql_execute( r_OQL_Query & query, r_Set<r_Ref_Any>& result, int dummy, |
| | 827 | r_Transaction* transaction); |
| 827 | 828 | |
| 828 | | void r_oql_execute( r_OQL_Query & query, r_Set<r_Ref<r_Any>> & result_set ) |
| | 829 | void r_oql_execute( r_OQL_Query & query, r_Set<r_Ref<r_GMarray>> & result_set, |
| | 830 | r_Transaction* transaction ) |
| 829 | 831 | |
| 830 | | The first version is used for ``insert``, ``update``, and ``delete`` statements |
| 831 | | where no result is passed back. The second version is used for ``select`` |
| | 832 | void r_oql_execute( r_OQL_Query & query, r_Set<r_Ref<r_Any>> & result_set, |
| | 833 | r_Transaction* transaction ) |
| | 834 | |
| | 835 | The first version is used for ``insert`` (until v9.1), ``update``, and ``delete`` |
| | 836 | statements where no result is passed back. The second version is used for |
| | 837 | ``insert`` queries, where the result contains the unique OID of the inserted |
| | 838 | object; the third parameter has no function and is there to distinguish this |
| | 839 | from the next two versions. The third version is for executing ``select`` |
| 832 | 840 | statements where an MDD is returned; in this case, the second parameter |
| 833 | | receives the query result. The third case is for general query results |
| | 841 | receives the query result. The final case is for general query results |
| 834 | 842 | which may also contain non-MDD return values, e.g., resulting from |
| 835 | 843 | ``select oid(...)`` or ``select sdom(...)`` statements. This version will also be |
| 836 | 844 | used when the result type of a query is not known in advance (i.e., at |
| … |
… |
Class ``r_Interest_Tiling``
|
| 1252 | 1260 | The class ``r_Interest_Tiling`` implements the *areas of interest tiling* |
| 1253 | 1261 | algorithm. The user specifies which areas are of interest (areas which |
| 1254 | 1262 | are accessed very often) and tiling is performed accordingly, in order |
| 1255 | | to optimize access to those areas. |
| | 1263 | to optimize access to those areas. |
| 1256 | 1264 | |
| 1257 | 1265 | .. figure:: media/dev-guide-c++/image12.png |
| 1258 | 1266 | :align: center |
| … |
… |
error situations:
|
| 1512 | 1520 | rasdaman Error Classes |
| 1513 | 1521 | |
| 1514 | 1522 | |
| 1515 | | Class r_Error |
| 1516 | | -------------- |
| | 1523 | Class ``r_Error`` |
| | 1524 | ----------------- |
| 1517 | 1525 | |
| 1518 | 1526 | This class implements the relevant part of the ODMG C++ binding's |
| 1519 | 1527 | ``r_Error`` class. It extends exception handling through deriving special |