This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
To my dear LightSpeed product development friends, Has there been any thought to lifting the requirement to always have a backreference in LightSpeed managed object relationships? We are finding that this is the culprit in developers unintentionally creating memory leaks within applications that maintain state (like windows apps). The core scenario where this keeps cropping up is exemplified below: Consider that the application uses a type "Category". The Category type represents reference data, is used to create the contents of a dropdown, is frequently used, and is cached within the application's client layer. Also consider that there is a "transactional" type "Song". Within a business domain, Songs must exist within a category. Implemented in an object model, the Song type defines a "Category" member of type Category. Consider that when a Song is created its "Category" member is set to a Category instance that is cached and then SaveChanges is called on the appropriate unit of work. After we are finished with this logical unit of work, other Song instances are created or modified etc. Because Category has a backreference to Song, the cached instance of "Category" maintains object references to the set of songs that it was associated with. If no backreference existed, the Song object being edited would be allowed to be garbage collected when it went out of scope but since a backreference is required, the set of Songs continues to pile up eating up more and more memory. This is a simple contrived example and in reality the type that correlates to "Song" in our application is a weighty object graph itself and gobbles up quite a bit of memory when kept around through backreferences. Our workarounds for this all have undesirable side-effects: Workaround 1: Assign ID's instead of reference data type object instances. Effect: More "lookups" are necessary in the application layer for simple tasks, some business logic gets pushed to the app layer instead of the "domain layer". Workaround 2: Create a parallel object type graph that maps to the same reference data table(s). ie create a "CategoryInfo" type that is a bit more lightweight than "Category" and convert from "Category" to "CategoryInfo" object instances when assigning these values to a Song instance. Effect: In order to keep from putting new rows in reference data tables, we must manipulate EntityState and ID through reflection. This can't be good. For reference data that is an "object graph" we have parallel type hierarchies that are terribly similar and updates to a single table schema affect several classes. Workaround 3: Clone reference data objects everytime they are served from Cache. Effect: Cloning is slow and has introduced performance bottlenecks. Simply removing the backreference requirement would mitigate all of this. Can you do it? Thanks
|
|
|
Let me be sure I've understood the requirement correctly. You have two entity types, Song (transactional entities) and Category (reference data). You want a Song to have reference to a Category, i.e. the association is maintained and can be traversed in the "many to one" direction. But you do *NOT* want a Category to have a Songs collection, i.e. the association is not maintained in the "one to many" direction. (The reason I am spelling this out is that in the designer we use "backreference" to refer to the to-one direction, i.e. the Song.Category member. So I just wanted to check that this is a difference in terminology rather than me misunderstanding your requirement.) |
|
|
You've got my request exactly. Sorry I threw you off with the clash in terminology. |
|
|
oops, wrong account, that was me |
|
|
Thanks for the confirmation. Just to update you on where we stand with this, we now have a proof of concept solution which *appears* to be working, but it's going to need a bit of bashing into shape before I have enough confidence to release it even for beta testing. We're pretty heavily loaded at the moment so it may take a while to get round to this -- almost certainly not before the middle of next week, and no promises even then. Keep chasing us though! |
|