TEAM: Ability to creat/load a singleton collection.

BenHayat

@Team;

Just like SystemSettinga which is a singleton object, is it possible for us developers to designate a "collection/list of objects" to be singleton, meaning once a process creates or loads that list in memory, the list remains cached and accessible for all users as long as the server is up?

There are cases, that we may have a list objects, i.e. list of state, or some static list that don't change very frequently and everyone can use it. These can be loaded after a BS gets loaded and then stay available for all users, as long as in configurator, they are marked as "Load it with BS". This will provide a lot more performance and saves a lot of memory on the server side, where each user doesn't have to load his own.

Is such feature available in Aware? If not, could you please consider adding this to Aware?

Thanks!

hpl123

1+, good idea

ACDC

I may be wrong, but I think that happens anyway ie . When a user loads a list for the first time it stays in memory for other users as well

BenHayat

Could Support verify how this process takes place in Aware server?

Thanks!

yuri.rj

Can't u load a "singleton" BO in an attribute of SystemSettings after start the server?

Then u can access SystemSettings.MySingletonBO.WhatEver..

Wouldn't it solve the problem?

BenHayat

yuri.rj wrote
Can't u load a "singleton" BO in an attribute of SystemSettings after start the server?

Then u can access SystemSettings.MySingletonBO.WhatEver..

Wouldn't it solve the problem?

Thank you for the interesting reply. Let's dissect it a bit, just to make sure we're on the same page and then see if your proposal meets the request.

Ok, the idea was to be able to have a global collection/list of instances of an object (i.e. states) that is cached in Aware server, so anytime any user in the app, clicks on a combobox to get a list of states, Aware would use this global cached list, rather than fetching that list from DB for that user's request.
This would save memory and DB access, especially in cases where there are a lot of users, constantly hitting same data. This was the goal.

So, are you suggesting that if I create an object (State) in Aware, populate it with all states and then go to systemSettings and create a 1-to-many relationship between States and SystemSettings (let's name it MyStates in SystemSettings), then any objects that is reference from SystemSettings, would also become a "Singleton" object(s) that remain in global Context and not User Context, which is cached and shared among all users???
Did I understand you correctly?
If yes, how do we guarantee those reference objects are also singleton objects?

I like your proposal, but I just want to get some clarifications as how Aware does this.
Thanks Again.

customaware

Sounds like a great idea yuri.

I just wonder if an objects reference attributes are loaded
at the same time as the object itself.

In fact I can see why you might want to have
A number of reference attributed hanging off SystemSettings.

Will test it out.

BenHayat

eagles9999 wrote
I just wonder if an objects reference attributes are loaded

Depends on if Aware does "Eager Loading" or "Lazy Loading". As I'm still new, I'm not sure If we can tell Aware to do eager or lazy loading.

yuri.rj

Actually its a little bit more complicated i think....

When we say "singleton" it confuses a little because a singleton its not a list of elements loaded in memory

So what i was thinking is to have a lsit(like States) loaded in SystemSettings...
But after i posted i was thinking and its not going to work. When u create another BO and say that u have an attribute called State, you'll have to specify the LIST of STATES and it does not allow to use SystemSettings.States. It only allow you to have a query that return these states... So you wil have to search anyway...

I use this much, but not on this situation...
I usually have predefined BO's but it needs to search when exist the possibility for the user to select.

Ex. I have a list of users to be contacted when something happen... There is no need to search... i just send e-mails to that guys...
If i needed the user to select which of those users would be contacted, i would need to have a search "WHERE RegularUser IN SystemSettings.PREDEFINEDUSERS" and then the user would select...

But i think you will always have to go to the DB...

Sorry about that...

And i'm sorry about my english too...

hpl123

Yuri,
I agree, great idea and might not work fully according to Ben´s requirements but has a lot of other use cases I hadn´t thought about before. Thanks

aware_support

1) Aware IM uses internal caching of objects quite effectively.
2) Aware IM does not support "session objects" that stay in memory while the user session is alive. Introducing this concept would complicate the product and we don't want to do this
3) Some "global" objects that are loaded in memory without a session are even worse in this sense - the concept is too complicated for the benefits
that it may give
4) There is no reason why you would need such objects - storing session objects in a database is less error prone and only marginally affects performance (especially with caching mentioned in 1)

BenHayat

aware_support wrote
1) Aware IM uses internal caching of objects quite effectively.
2) Aware IM does not support "session objects" that stay in memory while the user session is alive. Introducing this concept would complicate the product and we don't want to do this
3) Some "global" objects that are loaded in memory without a session are even worse in this sense - the concept is too complicated for the benefits
that it may give
4) There is no reason why you would need such objects - storing session objects in a database is less error prone and only marginally affects performance (especially with caching mentioned in 1)

Thanks Support for covering this topic. This way, I can avoid some of the directions I was considering.

I suppose # 2 hints at my other thread related to "Memory Variables" that also sounds like Session Objects. Which I should stay with persisted objects.

Thanks again!