On 27/12/2020 17:48, Dimitris Spanos wrote:
Hi Andy,

Thanks for your answer. The dataset cleanup operation I am referring to is
just closing a database pool.

Given that my custom dataset is read-only, after an abnormal server
shutdown, I would expect no dataset recovery actions are needed and the
only impact would be a few open connection pools.

Despite that the latter cannot be avoided, I think it's still beneficial to
try to handle graceful shutdown by closing the open pools.

Agreed - more friendly for an external resource that timeouts eventually.

As long as you're not assuming the dataset will have shutdown code called because sometimes it won't!

    Andy


On Sun, Dec 27, 2020 at 7:18 PM Andy Seaborne <[email protected]> wrote:

Hi Dimitris,

On 27/12/2020 14:08, Dimitris Spanos wrote:
Hi all,

I was wondering if there is a registry in ARQ or Jena base that keeps
track
of all registered datasets?

There isn't.

Such a registry would be helpful, since I have a custom
Dataset/DatasetGraph implementation and I would like to perform some
resource cleanup during JenaSubsystemLifecycle.stop() for every dataset.
I am aware of DataAccessPointRegistry but from an architectural point of
view, I would not want my Jena submodule to depend on Fuseki.

Any dataset implementation has to survive reality.:-)

Reality includes (machine|process|JVM) crashes, "kill -9" and
System.exit(0) and nasty things in transactions like out of disk space.

Datasets have to cope with unexpected stops. For example, when a TDB(1
or 2) dataset starts, it check whether any recovery actions are needed
and does them as it starts,

Because that happens, clean shutdown can only be an "extra". Once you
trust the recovery, adding clean shutdown is extra work.

What sort of clean shutdown does you dataset impl wish to do?

      Andy

Right now, I have implemented a Singleton dataset registry for my custom
datasets (registration happens during dataset assembly), but I am curious
to know if there is another/better way to retrieve registered datasets.

Regards,
Dimitris



Reply via email to