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 |