Usage of OOP - when is it stable ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Usage of OOP - when is it stable ?

GLASS mailing list

Hello,

we do our development in Gemstone totally via APIs.

So the developer in general transfers ids of objects with the API calls with additional informations (e.g. additional ids for a lookup path) so the lookup can be done in a mangeable time frame (with each API call). The lookup path also gives an indication, if the api-user still has a valid view in its client.

The lookup is still time consuming and I would like to consider using the numerical oop numbers for references. But I do not understand fully the constraints of these oop.

The oop should be stable under certain circumstances:

* as long as the object lives it has the same oop (not changed by GC)

* within different concurrent running sessions (gem), an object alwas has the same returned oop (????????????????)

* if the objects is not referenced any more, the oop may be reused

* I lookup the object via the oop number and always do additional checks to see, if the object is the expected one (expected class, associations to other object)

So my question - is the oop useable for that ? The documentation says, that the oop is not a reference. Or are there any other IDs available for that ?

The purpose is to get a very fast access to objects in the database - without any additional large sets and indices included.


Marten


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Usage of OOP - when is it stable ?

GLASS mailing list
The oop is stable from the time it is committed to the database (anObj isCommitted == true) up until the time the object is no longer referenced and is collected by the garbage collector.  Using the oop as a reference is safe to do so long as you understand these limitations.


On 2/10/2018 3:48 AM, Marten Feldtmann via Glass wrote:

Hello,

we do our development in Gemstone totally via APIs.

So the developer in general transfers ids of objects with the API calls with additional informations (e.g. additional ids for a lookup path) so the lookup can be done in a mangeable time frame (with each API call). The lookup path also gives an indication, if the api-user still has a valid view in its client.

The lookup is still time consuming and I would like to consider using the numerical oop numbers for references. But I do not understand fully the constraints of these oop.

The oop should be stable under certain circumstances:

* as long as the object lives it has the same oop (not changed by GC)

* within different concurrent running sessions (gem), an object alwas has the same returned oop (????????????????)

* if the objects is not referenced any more, the oop may be reused

* I lookup the object via the oop number and always do additional checks to see, if the object is the expected one (expected class, associations to other object)

So my question - is the oop useable for that ? The documentation says, that the oop is not a reference. Or are there any other IDs available for that ?

The purpose is to get a very fast access to objects in the database - without any additional large sets and indices included.


Marten



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Usage of OOP - when is it stable ?

GLASS mailing list

Thanks, so its stable for my purposes ...


Marten


Norm Green via Glass <[hidden email]> hat am 10. Februar 2018 um 18:29 geschrieben:

The oop is stable from the time it is committed to the database (anObj isCommitted == true) up until the time the object is no longer referenced and is collected by the garbage collector.  Using the oop as a reference is safe to do so long as you understand these limitations.


On 2/10/2018 3:48 AM, Marten Feldtmann via Glass wrote:

Hello,

we do our development in Gemstone totally via APIs.

So the developer in general transfers ids of objects with the API calls with additional informations (e.g. additional ids for a lookup path) so the lookup can be done in a mangeable time frame (with each API call). The lookup path also gives an indication, if the api-user still has a valid view in its client.

The lookup is still time consuming and I would like to consider using the numerical oop numbers for references. But I do not understand fully the constraints of these oop.

The oop should be stable under certain circumstances:

* as long as the object lives it has the same oop (not changed by GC)

* within different concurrent running sessions (gem), an object alwas has the same returned oop (????????????????)

* if the objects is not referenced any more, the oop may be reused

* I lookup the object via the oop number and always do additional checks to see, if the object is the expected one (expected class, associations to other object)

So my question - is the oop useable for that ? The documentation says, that the oop is not a reference. Or are there any other IDs available for that ?

The purpose is to get a very fast access to objects in the database - without any additional large sets and indices included.


Marten



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


 
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

 
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Usage of OOP - when is it stable ?

GLASS mailing list
Oop value is great for quick lookups - but remember they can be re-used after the garbage collector runs.  So be sure to factor that into your design if you store the values outside Gemstone

On Sat, Feb 10, 2018 at 10:03 AM, Marten Feldtmann via Glass <[hidden email]> wrote:

Thanks, so its stable for my purposes ...


Marten


Norm Green via Glass <[hidden email]> hat am 10. Februar 2018 um 18:29 geschrieben:

The oop is stable from the time it is committed to the database (anObj isCommitted == true) up until the time the object is no longer referenced and is collected by the garbage collector.  Using the oop as a reference is safe to do so long as you understand these limitations.


On 2/10/2018 3:48 AM, Marten Feldtmann via Glass wrote:

Hello,

we do our development in Gemstone totally via APIs.

So the developer in general transfers ids of objects with the API calls with additional informations (e.g. additional ids for a lookup path) so the lookup can be done in a mangeable time frame (with each API call). The lookup path also gives an indication, if the api-user still has a valid view in its client.

The lookup is still time consuming and I would like to consider using the numerical oop numbers for references. But I do not understand fully the constraints of these oop.

The oop should be stable under certain circumstances:

* as long as the object lives it has the same oop (not changed by GC)

* within different concurrent running sessions (gem), an object alwas has the same returned oop (????????????????)

* if the objects is not referenced any more, the oop may be reused

* I lookup the object via the oop number and always do additional checks to see, if the object is the expected one (expected class, associations to other object)

So my question - is the oop useable for that ? The documentation says, that the oop is not a reference. Or are there any other IDs available for that ?

The purpose is to get a very fast access to objects in the database - without any additional large sets and indices included.


Marten



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


 
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

 

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass