Transactions in Google AppEngine storage, how to bypass the restriction?

Question

Google Cloud Platform

I'm trying to work with Java JDO, but as I understand it, the problem is in the datastore itself. Due to a bunch of restrictions on the structure of the database and the use of transactions, it becomes necessary to create transactions for at least some objects, the structure of which can be made intentionally simple.
The task is actually a little different:

Simplified example:
There are 2 types of objects - User {id,name} and Item {id,name,user_owner:nullable}, the relationship between them is One-to-Many, while there may be instances of the Item object that do not belong to anyone. Item instances can move between different Users

Those. in this example, in terms of the GAE datastore, the root object can become inherited and vice versa. Established 'relationships' do not allow (more precisely, I failed) to move Item instances between different Users (even if you call pm.makePersistent after each change...) although they are supported, although it’s not a problem to start your own counter ... almost), since there is no other way to find out what identifier the system issued to a new object until it is saved or pm.close().
Everything would be fine, the implementation of relations through its keys does not impose any restrictions on their type, but there is a problem with transactions - in the GAE datastore, transactions operate exclusively within the same group of objects (and the group is connected by regular relations 1-M or 1-1 , in fact, there are still restrictions).
As you understand, it is almost impossible to create and maintain a more or less complex database without transactions, especially if the platform itself, on almost any sneeze, can interrupt the execution of a request anywhere ... if changes can still be rolled back manually (although this is still a task) , then how to organize a lock on access without transactions ..?
Since transactions in GAE are actually blocking at the level of object instances, I would like to be able to block access to specified objects, and according to the list

For example, in the above example:
It is possible to create a fictitious instance of the User object for the 'nobody' Item.
Accordingly, blocking can be carried out only on access to User objects
. Naturally, it may be necessary to block access to several User instances at once within one transaction.
For example, when moving an Item Between different Users, you can first block access to these Users and then carry out the move, respectively, assigning 'free' Items or 'release' busy ones, you get exactly the same task.

How can this be implemented at all, maybe there will be more ideas? Really no one faced this typical task at GAE, or everyone hopes 'at random', or does GAE somehow protect applications from parallel access to data in an undocumented way?
ps the best thing that comes to mind is to organize your own semaphores based on memcache (MemcacheService.Put using the ADD_ONLY_IF_NOT_PRESENT strategy) but this also does not guarantee anything, although it reduces the probability of failure by many orders of magnitude (the probability that the value from the cache will be deleted faster than it ends 'transaction' is vanishingly small, although there is a chance that when transferring between physical instances, the application will not see the previously created values)

Answer 1

Your situation is strange. Perhaps you should contact Google support, they respond quickly. Or use memcache.

Answer 2

Why don't you want to use JPA? The standard implements a good transaction management model, and since Google supports JPA, or rather implements it, it seems like everything should be in order?

Answer 3

You can already see for yourself that there are serious problems with storage in GAE, the complexity of which grows with the complexity of the project.
Therefore, I advise you to simply leave GAE for simple tasks and abandon it, and use a normal Java platform on shared hosting for your project.
The time you save by not solving problems you don't need can pay for hosting many, many times over.