Транзакциии в хранилище Google AppEngine, как обойти ограничение?

Без разницы, хоть low level API использовать, это ограничения самой google datastore, JDO/JPA это просто для более легкого переноса кода из уже готовых Java проектов, причем в самой документации написано, отключать транзакции, если модель не совместима с требованиями datastore.

Транзакциии в хранилище Google AppEngine, как обойти ограничение?

с чем? с просьбой сделать нормальные транзакции? форумы и так завалены вопросами как реализовать отношения в GAE… слишком неприятные ограничения накладывает их datastore на модель данных.
p.s. увидел PersistenceManager.makeNontransactional может поможет, точнее позволит хотя бы блокировки сделать штатными средствами, а не через memcache… потом проверю

Реально ли вообще хоть что то гарантировать в GAE datastore (Java, JDO)?

Наверное потому что, из-за специфики задачи (gae — как небольшой модуль-прослойка к приложению, работающему с реляционной БД), я начал использовать JDO не так как предполагалось, без использования штатных 'отношений', соответственно везде по глупому query by fk и уже пытаюсь править данные в найденном… а когда начал мешать getObjectById и Query в пределах одной транзакции, то полезло. Попробуйте пример, я код дал, делов на три-четыре клика мышкой.

Как вам еще 'не очевидный баг'? JDO не обновляет данные для полей, значение которых было изменено при прямом доступе к полям класса (если их сделать public), но сохраняется, если изменения были сделаны в методах класса-объекта. Ненавижу создавать методы-сеттеры и геттеры там, где логически они просто лишние (про идеологию не надо, я все понимаю, чужой монастырь...), но об этом нетривиально догадаться,… в документации хотя бы подчеркнули!

Реально ли вообще хоть что то гарантировать в GAE datastore (Java, JDO)?

Без изменений, вне зависимости от его значения Query возвращает старое значение данных, и, если не переоткрыть pm, изредка — текущее.

Пока забил на это дело, постараюсь переоформить проект на более key-value и JDO-ориентированный код:

Исключить/минимизировать запросы Query на данные, изменяемые в пределах своих транзакций.
Везде где это возможно использовать доступ по ключу и отношения, исключить 'висячие данные' (ничейные экземпляры объектов, которые могут быть приписаны в последствии другим объектам), так как описать их невозможно (точнее я пока не знаю как) в пределах одной группы для реализации транзакций.

p.s. не посоветуют бывалые пользователи eclipse и appengine, как закрывать (кнопкой или еще лучше автоматически) предыдущий отладочный локальный запуск приложения при повторном запуске?

Кнопки на это дело нет, а если сохранить проект и не остановить его (мышкой в мааааленький красный квадратик попасть) то при перекомпиляции (автоматически при сохранении) кнопка остановки исчезает, но приложение остается запущенным, мало того, при запуске отладки новая версия приложения не ругается и делает вид что запущена, но реально запросы принимает старая, закрыть которую можно либо в процессах (еще разберись какая из них) либо закрыв весь eclipse. Задолбало, уже сколько раз на этом наламывался.

Реально ли вообще хоть что то гарантировать в GAE datastore (Java, JDO)?

Неа, все равно 'захлебывается', вставлял везде, где создается pm — после создания, до close, после транзакций,..

for /l %a in (1,1,30) do @curl 127.0.0.1:8888/test
Test repeat read: 221, queryed:221
Test repeat read: 222, queryed:222
Test repeat read: 223, queryed:223
Test repeat read: 224, queryed:224
Test repeat read: 225, queryed:225
Test repeat read: 226, queryed:226
Test repeat read: 227, queryed:226
Test repeat read: 228, queryed:228
Test repeat read: 229, queryed:228
Test repeat read: 230, queryed:229
Test repeat read: 231, queryed:231
Test repeat read: 232, queryed:231
Test repeat read: 233, queryed:232
Test repeat read: 234, queryed:234
Test repeat read: 235, queryed:235
Test repeat read: 236, queryed:236
Test repeat read: 237, queryed:237
Test repeat read: 238, queryed:238
Test repeat read: 239, queryed:239
Test repeat read: 240, queryed:239
Test repeat read: 241, queryed:240
Test repeat read: 242, queryed:241
Test repeat read: 243, queryed:242
Test repeat read: 244, queryed:243
Test repeat read: 245, queryed:245
Test repeat read: 246, queryed:245
Test repeat read: 247, queryed:246
Test repeat read: 248, queryed:247
Test repeat read: 249, queryed:249
Test repeat read: 250, queryed:250

p.s. кстати благодаря транзакции + закрытие и повторное открытие pm, после деплоя на appstore ошибку воспроизвести не удалось, наконец то Query возвращает то что только что было изменено, но к сожалению локально ошибка повторяется, а отладку удаленно вести можно только через логи, что печально.
К тому же создание pm считается дорогой операцией :( там и так приходится думать над каждым доступом к базе…

Реально ли вообще хоть что то гарантировать в GAE datastore (Java, JDO)?

Если добавить транзакции (ваш пример очень неудачный и не наглядный, одно переименовывание проперти фактори jdo.properties уже непосвященному создало бы проблем). Добавил строчки
Transaction tx = pm.currentTransaction();
...
tx.begin();
...
tx.commit();
...
finally
....
if(tx.isActive()) tx.rollback();
Стало чуть более гарантированно (провел сотню последовательных тестов), но все равно непонятно — Query в пределах транзакции возвращают старые данные, а getObject — текущие
Если разместить Query после tx.commit() то неопределенность возвращается, данные выдаются как новые так и старые.

Реально ли вообще хоть что то гарантировать в GAE datastore (Java, JDO)?

после записи данных, pm.close() и повторное создание ситуацию возвращает до — 'изредка сохраняет'.

Ограничение на длину имени пользователя?

шит <iframe srrc='...'/>

Ограничение на длину имени пользователя?

угу… пусть будут ники вида /> :)

Зарезать торренты в локалке?

Интересная реакция общественности ;)

Это чем же так плохо предложение попытаться решить проблемы обеих сторон? как 'пользователей' так и 'провайдера' (в данном случае это топиккастер). Что происходит сейчас, о чем постоянно жалуются в 'Я негодую' — очередной провайдер услуг, решает свои проблемы за счет клиентов, вместо того чтобы попытаться найти решение — удовлетворяющее обе стороны, компромиссы!

Я предлагаю вместо того чтобы запрещать пользователям вообще пользоваться сетью (а зачем еще нужна сеть, кроме как 'не качать' в ней?) я предлагаю дать им возможность качать так, чтобы не мешать работе провайдера (другим). Вариант с вебмордой по любому позволит нескольким пользователям одновременно, без опасений, что их логины пароли/hash-key к торрентам будут раскрыты (в крайнем случае пара строчек в вебморде, благо они практически все опенсорс), при этом общая шара — позволит не качать одно и тоже сразу всем, по крайней мере не загружать внешний канал.

Гаджет, датчик положения в пространстве, задача минимум - 'человека, а точнее головы'?

вот и хочу, прежде чем покупать дорогую (5-6.т.р) камер для этих целей, узнать, какую задержку будет вносить именно она, дешевые уже проверил, даже при идеальном освещении лаг порядка 200мс, это много.

Как организовать синхронизацию очень разных данных?

Кстати, еще интересный вариант использовать git с опцией --git-dir (чтобы не возникало конфликтов с синхронизируемыми репозитариями того же git).

Но в любом случае где то необходимо хранить актуальную версию дерева версий файлов (или мест), чтобы знать где находится самая последняя версия и кого с кем необходимо синхронизировать, обычно все это хранится в голове и контролируется вручную.