Speaking of performance (and who isn't)
We all stuff a bunch of variables in LIRU to communicate between processes. (i.e. You select a customer from a query, have a process that says: LoggedInRegularUser.selectedCustomer = Customer
so that when you later have another process / query / form, you can access the selected customer. While some of this data needs to persist between sessions, so much of it does not. Because of all the updates to this one record, there is a lot of contention (and db activity) in this one, small table. So I was wondering
How hard would it be for aware to have something VERY similar (so it is always in context) a NON-Persistant LoggedInRegularUser ish time BO. Stuff we need only during the current session, can be shoved into that BO.
Wonder how hard this would be to implement?
Bruce
LoggedInRegularUser as NON-Persist
-
- Posts: 2413
- Joined: Mon Jul 02, 2012 12:24 am
- Location: Ulaanbaatar, Mongolia
Re: LoggedInRegularUser as NON-Persist
I do it of a sorts Bruce not with NP but with a BO identified by Session ID which is deleted if necessary and recreated on every login
I use it for temporary stuff rather than bulking up LIRU.
Make sure you have at least a SessionID attribute and a ps_RegularUser. That way, when you start the next session, you can find it to delete it if necessary.
I use it for temporary stuff rather than bulking up LIRU.
Make sure you have at least a SessionID attribute and a ps_RegularUser. That way, when you start the next session, you can find it to delete it if necessary.
Cheers,
Mark
_________________
AwareIM 6.0, 8.7, 8.8, 9.0 , MariaDB, Windows 10, Ubuntu Linux. Theme: Default, Browser: Arc
Upcloud, Obsidian....
Mark
_________________
AwareIM 6.0, 8.7, 8.8, 9.0 , MariaDB, Windows 10, Ubuntu Linux. Theme: Default, Browser: Arc
Upcloud, Obsidian....
Re: LoggedInRegularUser as NON-Persist
But Mark, isn't that the same problem? Every time I make a change, it gets written to the database. Also, don't you have to have a FIND MYSessionBO where MySessionBO.sessionID = ???
We have the LoggedIn prefix. For performance I would like to have a LoggedInMemoryTable that is always in context and does not have to be read and does not write to the disk.
(Esp. for databases that do PAGE locking, with a LOT of concurrent users, this can affect performance.)
Bruce
We have the LoggedIn prefix. For performance I would like to have a LoggedInMemoryTable that is always in context and does not have to be read and does not write to the disk.
(Esp. for databases that do PAGE locking, with a LOT of concurrent users, this can affect performance.)
Bruce
-
- Posts: 2413
- Joined: Mon Jul 02, 2012 12:24 am
- Location: Ulaanbaatar, Mongolia
Re: LoggedInRegularUser as NON-Persist
You are correct Bruce.
The problem with np is that it needs to me more persistent than it currently is.... like for the entire session rather than only the life of the current process context.
Can't think of any other way
The problem with np is that it needs to me more persistent than it currently is.... like for the entire session rather than only the life of the current process context.
Can't think of any other way
Cheers,
Mark
_________________
AwareIM 6.0, 8.7, 8.8, 9.0 , MariaDB, Windows 10, Ubuntu Linux. Theme: Default, Browser: Arc
Upcloud, Obsidian....
Mark
_________________
AwareIM 6.0, 8.7, 8.8, 9.0 , MariaDB, Windows 10, Ubuntu Linux. Theme: Default, Browser: Arc
Upcloud, Obsidian....
Re: LoggedInRegularUser as NON-Persist
Bruce I hear you... I've gone down the path that Mark suggested and at the end of the day, it became more work and I was still writing to disk and had to go back to the basics.
I had actually requested the same a while back before you came on board but we still don't have a solution.
However, I did manage to remove a bunch of temporary attributes from LoggedInUser to a NP object for processes that were big and had lots of inner processes and I need to store variables between inner processes and loops. This hugely gave me performance by NOT writing to LoggedInUser and not triggering any rules and the variables would get clear at the end of process. In one test, a process that would take 4 minutes with writing to LoggedInUser would take 90 seconds to do it with NP object. So, I changed to NP in many places.
But your request is what we really need for the life of a session. In ASP, the call them Session variables and you can make them as user logs in and they get deposed when user logs out. We also have system Variables that are in memory for the life of the server.
These would be great to add to Aware.
I had actually requested the same a while back before you came on board but we still don't have a solution.
However, I did manage to remove a bunch of temporary attributes from LoggedInUser to a NP object for processes that were big and had lots of inner processes and I need to store variables between inner processes and loops. This hugely gave me performance by NOT writing to LoggedInUser and not triggering any rules and the variables would get clear at the end of process. In one test, a process that would take 4 minutes with writing to LoggedInUser would take 90 seconds to do it with NP object. So, I changed to NP in many places.
But your request is what we really need for the life of a session. In ASP, the call them Session variables and you can make them as user logs in and they get deposed when user logs out. We also have system Variables that are in memory for the life of the server.
These would be great to add to Aware.
Re: LoggedInRegularUser as NON-Persist
I just did a search "Java garbage collection session" and there is a Java object called HttpSession that would do the trick. It seems to be a NP BO that garbage collection ignores while the session is active. It would result in more memory overhead, but given the alternatives...
v8.1 on Windows 10 / MySQL 5.6 (local), v8.1 on Windows Server 2016 / MySQL 5.6 (server)
Re: LoggedInRegularUser as NON-Persist
Jon, thanks for giving me a direction, I am just thinking out loud now, but figure I can write a couple of JS functions
set(paramName, value) and get(paramName)
The set would be easy, can just send the BO.attrib, so, for instance, if I want to save the current selected customer I can have set('customerID, Customer.ID)
but now in another process I want to read the current selected customer, to do this, I would need to get this value into some attribute. I can create a NP BO with a numeric field, but I am not sure how I can call a script and get the result of that script "shoved" into an attribute. hummmm... There should be an elegant solution but I have not thought of one yet. hummm, perhaps have the BO where I want the result to call a REST service to read this.
Bruce
set(paramName, value) and get(paramName)
The set would be easy, can just send the BO.attrib, so, for instance, if I want to save the current selected customer I can have set('customerID, Customer.ID)
but now in another process I want to read the current selected customer, to do this, I would need to get this value into some attribute. I can create a NP BO with a numeric field, but I am not sure how I can call a script and get the result of that script "shoved" into an attribute. hummmm... There should be an elegant solution but I have not thought of one yet. hummm, perhaps have the BO where I want the result to call a REST service to read this.
Bruce
Re: LoggedInRegularUser as NON-Persist
you could achieve this by saving variables and their values in the HTML document itself in a 'display: none;' element, which contains child elements which each carry a variable/value pair.
such child element could have an id which is the name of the variable, so that it can be accessed via,
document.getElementById("variable_name");
EXEC SCRIPT could be used to add/modify/delete variable/value pairs.
OR, even simpler still, you could achieve this by using the existing body element (or any element) of the HTML document and adding data- attributes to it:
document.getElementsByTagName("body")[0].setAttribute("data-sel_cust_id", "variable_value");
accessing variables:
document.getElementsByTagName("body")[0].getAttribute("data-sel_cust_id");
You just have to work out how to get variable values into a non-persistent BO when they need to be used.
Background: "
data-* attributes are used to store custom data private to the page or application.
data-* attributes give the ability to embed custom data attributes on all HTML elements.
Stored (custom) data can then be used in the page's JavaScript to create a more engaging user experience (without any Ajax calls or server-side database queries).
data-* attributes consist of two parts:
The attribute name should not contain any uppercase letters, and must be at least one character long after the prefix "data-"
The attribute value can be any string
Note: Custom attributes prefixed with "data-" will be completely ignored by the user agent.
data-.. attributes are new in HTML5. So to cater for non-HTML5 scenarios you might need to create custom attributes in the body element of the HTML document, with a prefix to ensure they are not defined HTML attributes."
https://developer.mozilla.org/en-US/doc ... attributes
https://www.w3schools.com/tags/att_global_data.asp
such child element could have an id which is the name of the variable, so that it can be accessed via,
document.getElementById("variable_name");
EXEC SCRIPT could be used to add/modify/delete variable/value pairs.
OR, even simpler still, you could achieve this by using the existing body element (or any element) of the HTML document and adding data- attributes to it:
document.getElementsByTagName("body")[0].setAttribute("data-sel_cust_id", "variable_value");
accessing variables:
document.getElementsByTagName("body")[0].getAttribute("data-sel_cust_id");
You just have to work out how to get variable values into a non-persistent BO when they need to be used.
Background: "
data-* attributes are used to store custom data private to the page or application.
data-* attributes give the ability to embed custom data attributes on all HTML elements.
Stored (custom) data can then be used in the page's JavaScript to create a more engaging user experience (without any Ajax calls or server-side database queries).
data-* attributes consist of two parts:
The attribute name should not contain any uppercase letters, and must be at least one character long after the prefix "data-"
The attribute value can be any string
Note: Custom attributes prefixed with "data-" will be completely ignored by the user agent.
data-.. attributes are new in HTML5. So to cater for non-HTML5 scenarios you might need to create custom attributes in the body element of the HTML document, with a prefix to ensure they are not defined HTML attributes."
https://developer.mozilla.org/en-US/doc ... attributes
https://www.w3schools.com/tags/att_global_data.asp
Last edited by pureist on Fri Sep 01, 2017 5:44 pm, edited 1 time in total.
Re: LoggedInRegularUser as NON-Persist
ok, thats cool. get to work on that Bruce and get us a working example
Click Here to see a collection of my tips & hacks on this forum. Or search for "JaymerTip" in the search bar at the top.
Jaymer
Aware Programming & Consulting - Tampa FL
Jaymer
Aware Programming & Consulting - Tampa FL
Re: LoggedInRegularUser as NON-Persist
how to use the value in a variable (AKA data-variable_name attribute of the body or other element of the HTML document)?
an alternative to approaching it on the basis of creating a non-persistent object instance..
EXEC SCRIPT could compile the data-variable_name attribute into a string which it executes directly using the JS eval() function:
var sel_cust_id = document.getElementsByTagName("body")[0].getAttribute("data-sel_cust_id");
eval("AwareApp.startProcess2('process_name','object_name'," + sel_cust_id + ",'render_option')");
..thus circumventing creating a NP instance.
Another option, if the above doesn't work is for EXEC SCRIPT to insert a new script element into the HTML document body (or other) element. Upon insertion the script will run. The new script element would contain:
AwareApp.startProcess2('process_name','object_name',instance_ID,'render_option');
The process which is run would remove the new script element to keep the document tidy.
an alternative to approaching it on the basis of creating a non-persistent object instance..
EXEC SCRIPT could compile the data-variable_name attribute into a string which it executes directly using the JS eval() function:
var sel_cust_id = document.getElementsByTagName("body")[0].getAttribute("data-sel_cust_id");
eval("AwareApp.startProcess2('process_name','object_name'," + sel_cust_id + ",'render_option')");
..thus circumventing creating a NP instance.
Another option, if the above doesn't work is for EXEC SCRIPT to insert a new script element into the HTML document body (or other) element. Upon insertion the script will run. The new script element would contain:
AwareApp.startProcess2('process_name','object_name',instance_ID,'render_option');
The process which is run would remove the new script element to keep the document tidy.