Альтернатива для Спящего режима или TopLink? [закрытый]
Вы можете попробовать следующие шаги:
- Использовать среднеквадратическую ошибку функцию потерь.
- Используйте Адама , который поможет вам быстрее сходиться с низкой скоростью обучения, такой как 0,0001 или 0,001. В противном случае попробуйте использовать оптимизатор RMSprop .
- Используйте регуляризаторы по умолчанию . На самом деле это не так.
- Поскольку это регрессионная задача, используют функцию активации, такую как ReLU, во всех слоях, кроме выходного слоя (включая входной слой). Используйте линейную активацию в выходном слое .
- Как уже упоминалось в комментариях @pooyan, нормализуют особенности . См. здесь . Даже попробуйте стандартизировать функции . Используйте то, что подходит лучше всего.
10 ответов
Как упомянуто, JPA <> EJB, они даже не связаны. EJB 3, оказывается, усиливает JPA, но это об этом. У нас есть набор материала с помощью JPA, который даже не близко подходит к выполнению EJB.
Вашей проблемой не является технология, это - Ваш дизайн.
Или, я должен сказать, Ваш дизайн не является легким соответствием на в значительной степени НИКАКОЙ современной платформе.
А именно, Вы пытаетесь поддержать транзакции по нескольким Запросам HTTP.
Естественно, почти каждая общая идиома - то, что каждый запрос является сам по себе одной или несколькими транзакциями, а не каждым запросом, являющимся частью большей транзакции.
Существует также очевидный беспорядок при использовании термина "не сохраняющий состояние" и "транзакция" в том же обсуждении как транзакции по сути с сохранением информации.
Ваша большая проблема просто справляется с Вашими транзакциями вручную.
Если Вы, транзакция происходит по нескольким Запросам HTTP И тем Запросам HTTP, оказывается, работаете "очень quicky", прямо друг после друга, то у Вас не должно действительно быть настоящей проблемы, сохранить это, необходимо будет удостовериться, что Запросы HTTP используют то же соединение с БД для усиления средства транзакции Баз данных.
Таким образом, простыми словами Вы получаете соединение с DB, наполняете его на сессии и удостоверяетесь, что на время транзакции, все Ваши Запросы HTTP проходят не только ту же самую сессию, но и таким способом, которым фактическое соединение все еще допустимо. А именно, я не полагаю, что существует от соединения JDBC полки, которое на самом деле переживет обработку отказа или выравнивание нагрузки от одной машины до другого.
Так, просто, если Вы хотите использовать транзакции DB, необходимо удостовериться что использование того же соединения с БД.
Теперь, если Ваша длительная транзакция имеет "взаимодействие с пользователем" в нем, т.е. Вы запускаете транзакцию DB и ожидаете пользователя, чтобы "сделать что-то", затем, вполне просто, тот дизайн неправилен. Вы НЕ хотите делать это, поскольку долговечные транзакции, особенно в интерактивной среде, просто Плохи. Как "Пересечение Потоков" Плохо. Не делайте этого. Пакетные транзакции отличаются, но интерактивные долговечные транзакции Плохи.
Вы хотите сохранить свои интерактивные транзакции столь же недолгими как практичными.
Теперь, если Вы НЕ можете удостовериться, что сможете использовать то же соединение с БД для своей транзакции, затем, поздравлений, Вы добираетесь для реализации собственных транзакций. Это означает, что Вы добираетесь для разработки системы и потоков данных, как будто у Вас нет транзакционной возможности на бэкэнде.
Это по существу означает, что необходимо будет придумать собственный механизм для "фиксирования" данных.
Хороший способ сделать это было бы то, где Вы создаете свои данные инкрементно в единственный документ "транзакции", затем подаете тот документ стандартной программе "сохранения", которая делает большую часть реальной работы. Как, Вы могли сохранить строку в базе данных и отметить ее, как "не сохранено". Вы делаете это со всеми Вашими строками и наконец называете стандартную программу, которая пробегает все данные, которые Вы просто хранили и отмечаете все это, как "сохранено" в единственной мини-пакетной обработке транзакции.
Между тем весь Ваш другой SQL "игнорирует" данные, которые не "сохраняются". Добавьте некоторые метки времени и сделайте, чтобы жнец обработал очистку (если Вы действительно хотите обеспокоиться - может быть на самом деле более дешево просто покинуть мертвые строки в DB, зависит от объема), эти мертвые "несохраненные" строки, поскольку это "uncomitted" транзакции.
Это не настолько плохо, как это звучит. Если Вы действительно захотите не сохраняющую состояния среду, которая является тем, на что она походит мне, то необходимо будет сделать что-то вроде этого.
Следите во всем этом, технология персистентности действительно не имеет никакого отношения к нему. Проблема состоит в том, как Вы используете свои транзакции, а не технологию так.
Я думаю, что необходимо взглянуть на апачскую Кайенну, которая является очень хорошей альтернативой "большим" платформам. С ее достойным разработчиком моделей кривая обучения, сокращаются хорошей документацией.
Если Вы после того, как другой поставщик JPA (В спящем режиме, является одним из них), затем смотрят на EclipseLink. Это намного более полнофункционально, чем ссылочная реализация JPA 1.0 Основ TopLink. На самом деле EclipseLink будет ссылочной реализацией JPA 2.0, поставленной с Финалом Glassfish V3.
JPA хорош, потому что можно использовать его как внутри, так и снаружи контейнера. Я записал клиентам Swing то использование JPA успешно. Это не имеет того же клейма и багажа XML, с которым шел EJB 2.0/2.1.
Если Вы после еще более легкого решения для веса затем смотрят не далее, чем ibatis, который я считаю своей предпочтительной технологией персистентности для платформы Java. Это легко, полагается на SQL (удивительно, сколько времени пользователи ORM тратят попытку заставить их ORM произвести хороший SQL), и делает 90-95% того, что делает JPA (включая ленивую загрузку связанных объектов, если Вы хотите).
Только исправить несколько точек:
- JPA является peristence слоем EJB, не основанного на EJB;
- У какого-либо достойного поставщика JPA есть большое кэширование продолжения, и может быть трудно понять все это (это было бы хорошим примером, "Почему Простота Так Сложна?"). Если Вы не делаете что-то, что у Вас нет indicatd, исключениями не должна быть проблема для Ваших управляемых объектов. Исключения на этапе выполнения обычно откатывают транзакции (при использовании управления транзакциями Spring и кто не делает этого?). Поставщик поддержит кэшируемые копии загруженных или сохраненных объектов. Это может быть проблематично, если Вы хотите обновить за пределами менеджера по объекту (требующий явной очистки кэша или использования
EntityManager.refresh()).
Я посмотрел на SimpleORM в прошлом году, и был очень впечатлен его легким дизайном без волшебства. Теперь, кажется, существует версия 3, но у меня нет опыта с тем.
BEA Kodo (раньше Solarmetric Kodo) является другой альтернативой. Это поддерживает JPA, JDO и EJ3. Это высоконастраиваемо и может поддерживать агрессивную упреждающую выборку, отсоединение/присоединение объектов, и т.д.
Хотя, от того, что Вы описали, Toplink должен смочь решить Ваши проблемы. Главным образом это кажется, что необходимо смочь присоединить/отсоединить объекты от слоя персистентности, поскольку запросы запускаются и заканчиваются.
Ни Не будьте в спящем режиме, ни Toplink (EclipseLink), основан на EJB, они - оба платформы постоянства POJO (ORM).
Я соглашаюсь с предыдущим ответом: iBatis является хорошей альтернативой платформам ORM: полный контроль над sql, с хорошим механизмом кэширования.
Еще одна опция является Крутящим моментом, я не говорю, что это лучше, чем любая из упомянутых выше опций, но просто что это - другая опция посмотреть на. Это становится довольно старым теперь, но может соответствовать некоторым Вашим требованиям.
Рассмотрите повреждение Вашей парадигмы полностью с чем-то как токсикология. При необходимости в классах Java, Вы могли бы загрузить результат XML в JDOM.
Когда я самостоятельно искал замену для Спящего режима, я наткнулся на Платформу обслуживания DataNucleus, которая является Apache2-лицензированным ORM. Это не просто ORM, поскольку это обеспечивает персистентность и извлечение данных также в других источниках данных, чем RDBMS, как LDAP, DB4O и XML. У меня нет опыта использования, но это выглядит интересным.
Ebean ORM ( http://www.avaje.org )
Это более простой и интуитивно понятный в использовании ORM.
- Использует аннотации JPA для отображения (@Entity, @OneToMany и т. Д.)
- Бессессионный API - без Hibernate Session или JPA Entity Manager
- Ленивая загрузка просто работает
- Поддержка частичных объектов для большей производительности
- Автоматическая настройка запросов с помощью «Автозапуска»
- Интеграция Spring
- Поддержка больших запросов
- Отличная поддержка пакетной обработки
- Фоновая выборка
- Генерация DDL
- Вы можете использовать необработанный SQL, если хотите (как и Ibatis)
Лицензия LGPL
Роб.