PDA

View Full Version : Blocking / synchronous AJAX call...



ssamayoa
11 Jan 2011, 1:30 PM
Hi.

Before scold me please let me explain.

I need to start a CDI conversation from ExtJS window/action, send to server various JsonStores changes then end the conversation, something like:



var cid = startTransaction();
try {
customerStore.save();
contactStore.save();
commit(cid);
} catch (e) {
rollback(cid);
// Do watever neede with exception...
// stores's callback "excepcion" function should throw js exception...
}
I need "startTransaction()", "commit()" and "rollback()" blocking AJAX calls since those are implemented as server.

Some ideas?

Thanks.

Dhugal
12 Jan 2011, 12:04 AM
If I were you I would group the changes up into a single request and do the transaction on the server side. What your suggesting has a number of fundamental problems... for example, what happens if the user closes their browser before the transaction is completed?

Let the server handle that side of things.

ssamayoa
12 Jan 2011, 6:08 AM
If I were you I would group the changes up into a single request

Of course but each time a complex data graph is maitained a custom JS and custom server code has to be writen.


what happens if the user closes their browser before the transaction is completed?

No problem since server conversations has a timeout and if occurs the transaction is rolled back.

The idea is simple:
When "transaction" starts in the server an entity manager (EM) is obtained, transaction is started then such EM is stored at conversation level and the conversation id (cid) is returned to the js code.

Each store's action is handled with its own servlet which in turns retrieve (via injection) the EM from conversation context and does whatever is has to do (create, update, delete). Of course cid must be sent from store to the server.

When "commit" is issued EM's transaction is commited, EM is closed then conversation is ended.

When "rollback" is issued EM's transaction is rolled back, EM is closed then conversation is ended.

When conversation times out, EM'S transaction is rolled back, EM is closed then conversation is ended. So, even if not properly handled by the js code, server prevents resource locking/retention.

BTW: I'm using CDI (Context and Dependency Injection JSR-299) in the servlet container.

Regards.

Dhugal
12 Jan 2011, 6:15 AM
OK so if I close my browser I potentially lock resources in the database for the duration of the timeout?

I have to say that there is a reason you don't see this pattern often if at all - because it's a bad idea. Letting the UI control transactions sends shivers up my spine.

There must be a generic way you can group up the changes and split them back out on the server - that's what I would be aiming for.

Something simple that wraps up the changes into a single packet which can then be unwrapped an executed on the server side in the correct order should be fairly straight forward and if you do it in a generic way you can re-use it throughout the application.

On the framework - sorry I don't work with Java so I can't comment on it.

ssamayoa
12 Jan 2011, 6:27 AM
OK so if I close my browser I potentially lock resources in the database for the duration of the timeout?

You can instruct to EM to flush changes (issues insert, update, delete to database) until commit so database locking doesnt occurs before that.

Regards.

ssamayoa
12 Jan 2011, 6:40 AM
It may seem to you strange and against "best practices" but I think in this schema because you can get modified records from store with Store.getModifiedRecords (http://localhost/ext/docs/source/Store.html#method-Ext.data.Store-getModifiedRecords)() but deleted records are not included.

Of course I can hack and use private fields as removed for example but changes in the API in the future will broke my code.

Regards.