I think you are definitely on the right track. The signature would likely have to change like this:

sealed trait ManagedCache[-Key, +Error, +Value] {
  def lookup(key: Key): ZManaged[Any, Error, Value]
}

object ManagedCache {
  def make[Key, Environment, Error, Value](lookup: Key => ZManaged[Environment, Error, Value]): ZManaged[Environment, Nothing, ManagedCache[Key, Error, Value] =
  ???
}

The ManagedCache would internally maintain a Ref[Int] representing the number of "observers" of each managed value. The acquire action of the ZManaged returned by lookup would increment this value, along with acquiring the underlying resource if necessary. The release action would decrement the number of observers and release the underlying resource if it was the last observer and the time to live had expired.

You can look at the implementation of the MemoMap data structure in ZLayer for an example of this pattern.

@adamgfraser Thank you a lot for your answer. Do you also mean I should in the final solution merge SharedManaged logic into ManagedCache instead of using composition?

I don't think there is any need for SharedManaged. It can all be done through ZManaged.

To go further on my work I think I need to add some unit test about expiration, I think this would be way easier if ManagedCache used ZIO.clock instead of using directly java.time. But I guess Cache use java.time directly for performance reason? Or can I go ahead and use ZIO.clock @adamgfraser ?

@strokyl The functionality to use the Clock for high performance applications exists in ZIO 2.0. I think given the timing it might make sense to update this PR for that. That will also allow you to use Scope which could potentially allow us to further unify the interface.

@strokyl The functionality to use the Clock for high performance applications exists in ZIO 2.0. I think given the timing it might make sense to update this PR for that. That will also allow you to use Scope which could potentially allow us to further unify the interface.

To be honest, I am working on this feature also because my team need it and so far with still on ZIO 1. I would prefer to firstly target ZIO 1 for this PR and after we work on making it use Scope

Okay. We are generally doing all new development on ZIO 2.0 but you are welcome to target your PR against whatever version you want. 😃

Okay. We are generally doing all new development on ZIO 2.0 but you are welcome to target your PR against whatever version you want. smiley

That sweet :). I wish I will find time to contribute later the migration of this code to ZIO 2.0, and I will probably because sooner or later my team will move to ZIO 2.0 (pretty soon I wish).
So I find a way to still using java.time.Instant and still be able to "control" the actual Instant.now result (cf my last WIP comment).

But while doing a test about expiration, I wonder what is better:

1. ensure the resource isn't too old only on managedCache.get call
2. ensure the resource isn't too old each time the manager returns by managedCache.get is used (call to .use on it).

I have the feeling 2 is the way to go but I am not sure about it.

Ok so I think my PR is now ready to review, I try to make reviews easier by the way I organize commits. In fact, my approach to code this feature was:

• to define the interface that managed cache should have (commit 3).
• use code of regular cache has a starting point (commit 4 which does not even compile)
• add a lot of tests and adapt the code copied from Cache (commit 5) to this new context.

The point was to make it easy to see how the cache code was adapted in the last commit.
About the test, I went a bit far with property testing but it definitely help me catch a lot of bugs. The consequence is that there is a lot of logic in ManagedCacheSpec, maybe I should move that logic (helpers and generator) to a separate file?

Minor comments on documentation but otherwise looks good!

Thank you for the review, I adapted the documentation in a new separated commit, tell me if this is ok for you and then we can merge the PR!

@strokyl Can you merge upstream changes?

I can't merge this PR because of:

 license/cla Expected — Waiting for status to be reported 

Ok so I follow this procedure:

Fix a stuck status check

Occasionally there is a glitch, whereby this status check fails to register, even though the contributor has already acknowledged their CLA. The message on the GitHub PR will be something like:
“license/cla Expected — Waiting for status to be reported”.

Being a required status check, this results in hold-ups with the PR.

One cause is when GitHub status is reporting problems with its notifications API, which the CLA agent uses to check PRs. Another cause might be the busy agent facility.

However, be patient. Sometimes it is just slow, and doing manual refresh might not help.

If it is truly seized, then the status check can be manually refreshed using a URL of the following form. Replace the <repo> with the repository name, and the <pr-number> with the pull-request number.

https://cla-assistant.io/check/folio-org/<repo>?pullRequest=<pr-number>

From: https://dev.folio.org/guidelines/cla-process/ and now it's all green