Type not persistable: "class java.lang.Thread" for customized class loader and Postgresql storage target

[to-do42]

As mentioned in the docs a customization is necessary if there are issues regarding different classloaders. For file based storagees the given solution works perfectly. Now I've switched to Postgresql as Storage targets and also use the code example given in the docs here.
But in this case, the following error occur:

org.eclipse.serializer.persistence.exceptions.PersistenceExceptionTypeNotPersistable: Type not persistable: "class java.lang.Thread".

This is the whole Spring Bean Config:

    // configured as usual via application.yml
    private final DataSource dataSource;
    private final Environment environment;

    public DatabaseConfiguration(DataSource dataSource, Environment environment) {
        this.dataSource = dataSource;
        this.environment = environment;
    }  

  @Bean(destroyMethod = "shutdown")
  @Primary
  public StorageManager defineStorageManager() {
        SqlFileSystem fileSystem = SqlFileSystem.New(
            SqlConnector.Caching(
                SqlProviderPostgres.New(dataSource)
            )
        );
  
        EmbeddedStorageManager storageManager = EmbeddedStorage.Foundation()
            .onConnectionFoundation(cf -> cf.setClassLoaderProvider(ClassLoaderProvider.New(
                Thread.currentThread().getContextClassLoader())))
            .start(fileSystem.ensureDirectoryPath("storage"));

        // Check Root available within StorageManager
        RootData root = (RootData) storageManager.root();
        if (root == null) {
            root = new RootData();
        } else {
            log.debug(root.toString());
            log.debug(root.getCustomers().toString());
        }

        storageManager.setRoot(root);
        return storageManager;
    }

What config is neccessary for Postgresql storage target plus the classloader customization ?

[hg-ms]

The PersistenceExceptionTypeNotPersistable is caused by an unpersistable type. In your case it’s java.lang.Thread. This Exception is thrown at runtime the first time you try to persist such a type and later during the storage startup phase.

To identify the problematic type that references a non-persistable type have a look into the type- dictionary, the PersistenceTypeDictionary.ptd file in the storage directory. It is a human readable text.

To repair a storage that does no more start just delete the affected type-description from the type dictionary file.

[to-do42]

Hi @hg-ms,
thank you for your response.
Unfortunately, there is no type-dictionary: the error occur during the initial start() phase of the Postgresql storage target together with those classloader customization. There are not even the both database tables storage$channel_0 and/or
storage in my Postgresql schema. If I switch to the other / default variant

EmbeddedStorageManager storageManager = EmbeddedStorage.start(fileSystem.ensureDirectoryPath("storage"));

both database tables are created, the table storagecontains an identifier PersistenceTypeDictionary.ptdbut without any Thread in the binary content. But in this case, the error is different: Without any store operation happened, after the next application start, the error TypeId inconsistency for RootData: typeDictionary type definition typeId = 1000072, validated type handler typeId = 1000076 occure, which seems to be related to the classloader issue. Therefor I use those classloader customization afterwards. Maybe this is not the correct way to handle this TypeId inconsistency error ?

[hg-ms]

As I am not able to reproduce the error I can give some tips only:
The TypeId inconsistency indicates that the type dictionary does not match the registered type handler. This may happen if you already started a storage with different type handlers configurated using the same Postgresql storage target.
In that case I’d recommend to delete the related Postgresql DB if possible.

An cause might be the SprinBoot Dev tools that may have caused the type differences. You can try to disable them.

An important thing to know is that starting an empty storage (no explicit Root set) cause writes. At least the default type dictionary and an empty internal root element is stored.