BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Persistence Framework Question: Linking to previously loaded Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Keith Whale Guest Posted: Tue Feb 03, 2004 3:35 pm    Post subject: Persistence Framework Question: Linking to previously loaded I have been working on a persistence framework and have run into a snag. The situation is when an object, call it Y, is being loaded from the persistent storage that is associated to an object, call it X, that was previously loaded into memory. With my first effort I simply loaded another copy of object X into memory. This approach worked but doesn't seem correct in that two "copies" of object X are in memory at the same time. I have considered keeping a list of all objects loaded so that if the same object is requested again the request can be directed to the existing object. However, this list would become quite large and additional code would be required to track when objects are freed, etc. I would appreciate any suggestions on how to approach this situation. I think I am missing something obvious. Thanks Keith Back to top Peter Morris [Droopy Eyes Guest Posted: Tue Feb 03, 2004 3:48 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo Option 1) Live with duplicates. Objects should be loaded/used/unloaded quickly as separate transactions. Option 2) Keep a repository of all objects, unload them if not used for X minutes. -- Pete ============= http://www.DroopyEyes.com - Delphi source code Audio compression components, Fast Strings, DIB Controls Read or write article on just about anything http://www.HowToDoThings.com "Keith Whale" <keith_12345 (AT) hotmail (DOT) com> wrote Quote: I have been working on a persistence framework and have run into a snag. The situation is when an object, call it Y, is being loaded from the persistent storage that is associated to an object, call it X, that was previously loaded into memory. With my first effort I simply loaded another copy of object X into memory. This approach worked but doesn't seem correct in that two "copies" of object X are in memory at the same time. I have considered keeping a list of all objects loaded so that if the same object is requested again the request can be directed to the existing object. However, this list would become quite large and additional code would be required to track when objects are freed, etc. I would appreciate any suggestions on how to approach this situation. I think I am missing something obvious. Thanks Keith Back to top Joanna Carter (TeamB) Guest Posted: Tue Feb 03, 2004 4:19 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo Peter Morris [Droopy Eyes Software] wrote: Quote: Option 1) Live with duplicates. Objects should be loaded/used/unloaded quickly as separate transactions. Option 2) Keep a repository of all objects, unload them if not used for X minutes. What more can I say? :-) -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Bob Dawson Guest Posted: Tue Feb 03, 2004 6:03 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo "Joanna Carter (TeamB)" wrote Quote: | Option 1) Live with duplicates. Objects should be | loaded/used/unloaded quickly as separate transactions. | Option 2) Keep a repository of all objects, unload them if not used | for X minutes. What more can I say? Option 3) Keep a ref-counted repository of all objects, unload them immediately whenever ref-count = 0. In general, doesn't seem to me that a framework really has any business holding on to objects the user has released. It may, however, maintain internal objects the user is unaware of, and maintain common resource objects (look-up lists) as optimizing implementation details (their status as resources is clearly marked, and generally they're used by the BOs anyway not directly by the application programmer). bobD Back to top Jim Cooper Guest Posted: Tue Feb 03, 2004 6:19 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo Keith, Quote: Option 1) Live with duplicates. Objects should be loaded/used/unloaded quickly as separate transactions. I've done this one, and in retrospect, it would have been better to have gone for the cache of objects. As long as you are referring to them with object references (ie pointers), you aren't taking up any extra space. Usually if you have two references to one (conceptual) object you would want them to be the same. This can be a problem if you have bidirectional lists (eg a list of matches for each player, and a list of players in each match). However, I have found that for some situations like reporting and exporting, it can be better to use a clean set of objects, if only because you may want to load them more efficiently. Quote: Option 2) Keep a repository of all objects, unload them if not used for X minutes. I don't think there's any need for x minutes in most apps, but there will be a need to remove them eventually. Bob's reference counting idea appeals. What you do when deleting an object is an interesting question with this approach though :-) Cheers, Jim Cooper _______________________________________________ Jim Cooper [email]jim (AT) falafelsoft (DOT) com[/email] Falafel Software http://www.falafelsoft.co.uk _______________________________________________ Back to top Keith Whale Guest Posted: Tue Feb 03, 2004 6:52 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo Thanks for all your comments and help. I will go with a cache of objects. As well, I believe I should provide something similar to Delphi's FreeList to ensure references between objects remain valid. "Jim Cooper" <jim (AT) falafelsoft (DOT) com> wrote Quote: Keith, Option 1) Live with duplicates. Objects should be loaded/used/unloaded quickly as separate transactions. I've done this one, and in retrospect, it would have been better to have gone for the cache of objects. As long as you are referring to them with object references (ie pointers), you aren't taking up any extra space. Usually if you have two references to one (conceptual) object you would want them to be the same. This can be a problem if you have bidirectional lists (eg a list of matches for each player, and a list of players in each match). However, I have found that for some situations like reporting and exporting, it can be better to use a clean set of objects, if only because you may want to load them more efficiently. Option 2) Keep a repository of all objects, unload them if not used for X minutes. I don't think there's any need for x minutes in most apps, but there will be a need to remove them eventually. Bob's reference counting idea appeals. What you do when deleting an object is an interesting question with this approach though :-) Cheers, Jim Cooper _______________________________________________ Jim Cooper [email]jim (AT) falafelsoft (DOT) com[/email] Falafel Software http://www.falafelsoft.co.uk _______________________________________________ Back to top Phil Shrimpton Guest Posted: Tue Feb 03, 2004 10:31 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo In article <401fbfb2$1 (AT) newsgroups (DOT) borland.com>, [email]keith_12345 (AT) hotmail (DOT) com[/email] says... Hi, Quote: I have considered keeping a list of all objects loaded so that if the same object is requested again the request can be directed to the existing object. However, this list would become quite large and additional code would be required to track when objects are freed, etc. This is essentially what we do. Our "LoadObject(..)" method first checks our 'object cache' for the object, before loading from the DB. To prevent the cache getting too big, it has a MaxSize property which caps the level, on a 'oldest used', 'first out' bases, it also has a MaxObjectLife property that will 'free' the object after a specified time after it was last used. Having a cache can have dramatic effects on performance (less DB reads), and it also means there is only ever one instance of a particular object, so concurrency/locking can be handled easier. Phil Back to top Peter Morris [Droopy Eyes Guest Posted: Wed Feb 04, 2004 8:10 am    Post subject: Re: Persistence Framework Question: Linking to previously lo I would suggest allowing for both. eg - LoadObject(UseCache: Boolean = True); Sometimes you may want to load a duplicate of an object from the DB. For example Form1 - Open object A Form1 - Edit something Form2 - Open object B (which links to object A in some way) Form2 - Invoke something which changes object A Form2 - Save changes objects (A and B) Form1 - Cancel changes The changes made in Form1 which you thought you had just cancelled were actually saved by Form2. Maybe this is another issue though :-) -- Pete ============= http://www.DroopyEyes.com - Delphi source code Audio compression components, Fast Strings, DIB Controls Read or write article on just about anything http://www.HowToDoThings.com Back to top Peter Morris [Droopy Eyes Guest Posted: Wed Feb 04, 2004 8:12 am    Post subject: Re: Persistence Framework Question: Linking to previously lo Quote: Option 3) Keep a ref-counted repository of all objects, unload them immediately whenever ref-count = 0. I opted for the X minutes because you may reuse the same object within X minutes of its last use. This would save having to refetch it from the DB. Obviously reference counting is a good way of determining "not used". -- Pete ============= http://www.DroopyEyes.com - Delphi source code Audio compression components, Fast Strings, DIB Controls Read or write article on just about anything http://www.HowToDoThings.com Quote: In general, doesn't seem to me that a framework really has any business holding on to objects the user has released. It may, however, maintain internal objects the user is unaware of, and maintain common resource objects (look-up lists) as optimizing implementation details (their status as resources is clearly marked, and generally they're used by the BOs anyway not directly by the application programmer). bobD Back to top Peter Morris [Droopy Eyes Guest Posted: Wed Feb 04, 2004 8:13 am    Post subject: Re: Persistence Framework Question: Linking to previously lo Quote: What more can I say? Well done? :-) Back to top Steven Camilleri Guest Posted: Wed Feb 04, 2004 9:43 am    Post subject: Re: Persistence Framework Question: Linking to previously lo If you keep objects in a Cache, what happens in a multiuser system, when another user has updated the object while it sits in your Cache? I prefer to load objects as and when needed, using proxies where possible. Steve Back to top Phil Shrimpton Guest Posted: Wed Feb 04, 2004 10:06 am    Post subject: Re: Persistence Framework Question: Linking to previously lo In article <4020a90a$2 (AT) newsgroups (DOT) borland.com>, support@_nospam says... Hi, Quote: I would suggest allowing for both. eg - LoadObject(UseCache: Boolean = True); Sometimes you may want to load a duplicate of an object from the DB. We only allow duplicate instances of objects if the second, and subsequent, instances are read-only. Multiple, 'editable', instances just adds to the complexity when it comes to concurrency, IMO. Quote: For example Form1 - Open object A Form1 - Edit something Form2 - Open object B (which links to object A in some way) Form2 - Invoke something which changes object A Form2 - Save changes objects (A and B) Form1 - Cancel changes The changes made in Form1 which you thought you had just cancelled were actually saved by Form2. Surely actions in 'Form1' would be in a different 'transaction' to 'Form2', so 'Form2' won't see the changes to object A? Phil Back to top Phil Shrimpton Guest Posted: Wed Feb 04, 2004 10:09 am    Post subject: Re: Persistence Framework Question: Linking to previously lo In article <4020bea9$1 (AT) newsgroups (DOT) borland.com>, [email]stevenc (AT) emb (DOT) co.uk[/email] says... Hi, Quote: If you keep objects in a Cache, what happens in a multiuser system, when another user has updated the object while it sits in your Cache? Not sure what you mean? If a user updates an object in the cache, those changes can be seen by other users (once the 'transaction' has committed). Phil Back to top Peter Morris [Droopy Eyes Guest Posted: Wed Feb 04, 2004 12:05 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo Quote: Not sure what you mean? If a user updates an object in the cache, those changes can be seen by other users (once the 'transaction' has committed). User 1 loads object "A", edits, saves User 2 loads object "A", edits, saves User 1 loads locally cached object "A", edits, saves At the third stage User 1 is working with an old object, this is what he means. Pete Back to top Phil Shrimpton Guest Posted: Wed Feb 04, 2004 12:37 pm    Post subject: Re: Persistence Framework Question: Linking to previously lo In article <4020e013$1 (AT) newsgroups (DOT) borland.com>, support@_nospam says... Hi, Quote: Not sure what you mean? If a user updates an object in the cache, those changes can be seen by other users (once the 'transaction' has committed). User 1 loads object "A", edits, saves User 2 loads object "A", edits, saves User 1 loads locally cached object "A", edits, saves At the third stage User 1 is working with an old object, this is what he means. Well this is the same situation as you get when using TClientDataSets and 'databases', and would be handled in much the same way. Phil Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.