Параллельное разрешение Hibernate UserType при возврате через attribute.list ()

Question

Встроенный пользовательский тип в Hibernate .....

Это аннулирует / маршаллизирует JAXB аннотированные объекты в строковые данные, которые передаются в столбец XML (внутри DB2).Перемещение данных между строками и Pojos занимает время .... около 7 мс (с проверкой или без нее).Проблема заключается в том, что если у меня есть набор результатов из 20 нечетных объектов, то последовательное преобразование данных выполняется.20 * 7 мс - это 140 мс, что достаточно, чтобы вытащить 20 элементов из таблицы.Использование Hibernate Criteria и метода list для возврата данных.

Есть ли способ обрабатывать результаты, которые Hibernate получает из канала JDBC параллельно?Так что 7 мс распределяются по параллельной обработке, сокращая время моего отклика до времени, которое JAXB необходимо преобразовать?

Искал через Google, но ничего не видел ...

Answer 1

Другим альтернативным решением было бы отказаться от пользовательского типа и смоделировать свойство как InputStream

public Thing {
    // use field access level
    private InputStream blob;

    @Tranisent       
    private Future<That> that;

    private static final ExecutorService executor = ExecutorService.newCachedThreadPool();

    public Future<That> getThat(){
        if( that == null ) {
            // lazily submit the creation to the executor
            that = executor.submit(new Callable<That>{/* implement call() */});
        } 
        return that;
    }
}   

Думаю, что это может быть немного более доступным, чем тип пользователя Future<That>

Обратите внимание, когда вы получаете список Thing, вам сначала нужно прокачать объекты перед тем, как пытаться получить доступ к значениям:

for( Thing thing: listOfThings ){
    thing.getThat() ; // for side effects
}                                        

for( Thing thing: listOfThings ){
    That that = thing.getThat().get();
}

Есть несколько проблем с этим.

1. Для Исполнителя нет четкого жизненного цикла. то есть как это будет отключение
2. Нет гарантии, что первый элемент в списке будет первым, кто вернет результат, возможно, использование ExecutorCompletationService даст лучшее решение

Answer 2

Интересная проблема.Моя первая мысль - попытаться смоделировать его как Future<Thing>.Ваш UserType может отправить задачу в Executor и вернуть Future.

. У вас, несомненно, будут некоторые интересные проблемы, связанные со временем (как со всем параллелизмом), плюс реализация остальной части интерфейса UserType (т.е. равно, hashCode и т. д.) становится намного сложнее.