there are no previous version where this just worked. you should not jump to conclusions without being familiar with the implementation.

I've been using the session storage implementation of Lucee (and Railo before that) for many years. I have written and maintained Lucee cahe extensions that provide session storage. I have read the code in depth. I have had many conversations directly with you about how it works. I feel I am well familiar enough with the implementation to have an opinion on it. I have also jumped to no conclusions.

I can unequivocally state that the session storage in Lucee used to work objectively better. Sure, even the older implementations had their issues, but the limitations in behavior introduced knowingly in these later versions apply unacceptable restrictions on how CF devs can use the session scope. Can't we all agree that we need to address this and stop making excuses for it?

the communication is kept as low as possible

This has been done at the expense of the session scope "just working" which is why it is an unacceptable solution. Lucee cannot tell CF devs "don't use structs in your session scope because we need to keep communication down".

Do not use deep structures. so instead of “session.foo.bar“ do “session.foo_bar“

That right there is what we are taking issue with. That design is unacceptable and we reject it. In fact, we don't even need to know how session storage work in order to reject that design at face value. Lucee needs to address this and change the design

cc/

agree, as long you use a storage only from a single instance, it should all work as expected. the setting sessionCluster should only be needed in case you use the storage from multiple instances and you want the storage to be the master. I simply wanna make clear that the fix is not downgrading to an older version.

Whether or not it worked previously and no longer works or this has always been the case, the fact remains that it is not compatible with Adobe’s implementation, and for so long as sessionCluster remains an option, I don’t think that it’s appropriate that a decision made in support of engine efficiency should alter how we are able to work with structs.

there are no previous version where this just worked. you should not jump to conclusions without being familiar with the implementation.

this is about master and slave and when the object is read from store and written back, the communication is kept as low as possible. we will analyze in detail and report here.

Hey / all. Ok, I’m caught up on this now, and you’re right--the dev team needs to reply to the points raised, and in doing so, either address them, or give additional details as to what we need. My personal opinion is that we don’t need more details at this point, but rather we need to discuss as team and decide. I’ll add it to the agenda for our weekly standup (which are on Mondays now, btw).

My personal inclination is to favor standardized behavior for Lucee in implementing distributed caching, since this is really the gold standard for n-scale systems. But let’s see what comes of the dev team discussion in the next standup. Stay tuned.