[Isomorphic]

Before any of the requests have been executed. For example, in a subclass of the IDACall Servlet.

[edulid]

dsRequest.getRPCManager().setTransactionPolicy(TransactionPolicy.ALL); cannot be set, since the operation has already begun. Where is the correct place to set this if I want to set it for this RPCManager?

[edulid]

A question regarding this:

If I set
dsRequest.getRPCManager().setTransactionPolicy(TransactionPolicy.ALL);

Then this policy will ONLY be set for this DMIMethod?
With other words, are other DMIMethods maybe using this same RPCManager?

[edulid]

I don't use 3.1, but the creater of this thread does:
http://forums.smartclient.com/showthread.php?t=32494

[Isomorphic]

To clarify - does this problem go away when you use the latest nightly build of 3.1p, available from the website? If so, does the problem go away because SmartGWT Server is handling all of the requests - including the fetches - as a single transaction (this would be the case if you see it using the same connection for each query, and a single commit at the end), or because it is committing the updates before running the fetches?



-

[Isomorphic]

Hmm, yes, sorry for the confusion. The docs are correct, the presence of an update operation in the queue will be enough to bundle everything into a transaction.

However, this only applies to real queues that come from the client as a series of DSRequests enclosed by calls to startQueue() and sendQueue(). In this case, the makeup of the queue is known in advance and is available to the RPCManager for the entire lifetime of the queue of requests it is managing.

Your case is different. It is not a real queue, it is just a number of server-created DSRequests that share an RPCManager because your code manually applies the RPCManager to the requests. No attempt is made to include DSRequests added in this ad hoc way when deciding whether a transaction policy like ANY_CHANGE is applicable to a given DSRequest, so we understand why you are getting the results you are. However, before we state categorically that this is the correct behavior, we want to clarify why this didn't also happen with release 3.1.

We will post back on this thread when we have investigated.

[edulid]

Thanks for the explanation.

I think I will change the transaction policy for DMI methods that have fetches after inserts/updates/deletes.

I read the docs again and I don't understand one part:
https://www.smartclient.com/smartgwt...olicy%28int%29

ANY_CHANGE: Bundle all requests into a transaction, including leading fetches, if there is any change operation in the queue. This is the default.

Here you say that in this case even fetches will be included into the transaction.

In my example, where I have an insert, and then a fetch, according to this docs, they should all be in the same transaction.
But you said earlier:

the "autoJoinTransactions" setting is "ANY_CHANGE", which means updates, adds and deletes in a single queue with a shared RPCManager will form a single transaction; the automatic cache-sync queries we run will also join this transaction, but regular fetch operations will not.

Here you say that fetches are not included into this transaction.
Are the docs here incorrect/misleading? Or am I misunderstanding something ?

[Isomorphic]

Yes, your reasoning is correct. The reason we don't have autoJoinTransactions: ALL out of the box is a desire to avoid introducing a transaction where it is not necessary and may impact performance. Any queue that consists of nothing but fetch operations falls into this category, but the most obvious example of when a transaction is unnecessary is a queue that contains just a single fetch operation. This is obviously a very common occurence, so we avoid adding unnecessary potential overhead. Of course, there are cases when a transaction is necessary to the correct operation of a fetch, but these are comparatively rare for most applications.

If you make the change to ALL and discover that it has an adverse performance impact on your plain fetch requests, you may wish to consider using a transaction policy of FROM_FIRST_CHANGE. Note, as discussed in the autoJoinTransactions doc we linked you to earlier, you can set the server.properties property "autoJoinTransactions" to a transaction policy as well as true/false, so if you want to do this, you don't have to programmatically call setTransactionPolicy() on every RPCManager instance - you can still apply this change declaratively.

[edulid]

Hi Isomorphic,

I haven't changed the autoJoinTransactions setting anywhere, so I should have the default setting "ANY_CHANGE".

As you described, updates, adds and deletes seem to use the same connection, but fetches not. I don't quite understand what is the reasoning of not including fetches into the transaction.

If I have a batch insert, and immediately I want to fetch the inserted rows, I need these two operations to be in the same transaction, so that I really get the inserted rows in my fetch. Or do I understand something wrong?

We have tried to reproduce the problem you are seeing - specifically, the problem that two DSRequests, run from a single server method and affecting the same row, end up using different database connections and thus causing a deadlock - but we are unable to do so with the default config shipped with SmartGWT.

The first request should be an insert, the second a fetch of the inserted row. If I understand correctly your explanation, under the default smartgwt settings, these should use different connections, since one is an insert, and the other a fetch (which doesn't join the transaction). Can you please confirm if my reasoning is correct?

If yes, I should change the setting to "ALL" instead of "ANY_CHANGE", I think. What are the pros/contras and problems of having the setting "ALL"? Why isn't this the default setting?

[Isomorphic]

The short answer is: it depends. As the framework is shipped, the "autoJoinTransactions" setting is "ANY_CHANGE", which means updates, adds and deletes in a single queue with a shared RPCManager will form a single transaction; the automatic cache-sync queries we run will also join this transaction, but regular fetch operations will not. This is all documented here

So the change described by andrerichards should not be necessary, unless you have changed or somehow overridden the autoJoinTransactions setting - as you will see by following the link above, there are many ways to do this, globally, or specifically for SQL Server, or for specific DataSources, operationBindings or even individual requests.

We have tried to reproduce the problem you are seeing - specifically, the problem that two DSRequests, run from a single server method and affecting the same row, end up using different database connections and thus causing a deadlock - but we are unable to do so with the default config shipped with SmartGWT.

Therefore, unless you know of a change you have made to autoJoinTransactions setup which would explain this, please share your .ds.xml files, your server.properties (and project.properties if you have one, and modified framework.properties if you have modified it) and the complete server classes that demonstrate the problem. If you don't want to post these on the forums, please zip them up and email to support@isomorphic.com

@andrerichards: likewise, unless you have made config changes which would explain why you had to override sql.SQLServer.autoJoinTransactions to true, if would be helpful if you could also provide the details we ask for above.

Regards,
Isomorphic Software Support

[edulid]

And further: is this a bug?
Shouldn't queries that should run in the same transaction (i.e. having the same rpcManager) run using the same connection and transaction, even if this setting is turned off?

[edulid]

Thanks, I will try this.

@Isomorphic, could you please confirm that the lack of this setting may be blocking the DB?

[andrerichards]

@ OP
Found that by setting autoJoinTransactions in the server.properties to true fixes the issue for me.

sql.SQLServer.autoJoinTransactions: true

[edulid]

Yes, I think this issue may be similar to andrerichards issue.
I am experiencing this issue with *and without* cursors.

I previously had a DMI Method, that only used DSRequest/DSResponses (server-side), and I had calls from the people in production, telling me that the DB had crashed. I wasn't able to solve the problem (nor to reproduce it) until I restarted the Tomcat server and sometimes even the DB.

I then changed the DMI Method to be completely executed in T-SQL and since then I have not experienced this DB blocking. So something is wrong with the SmartGWT DMIs. For complex operations I am not able to use the DMI, but I have to use directly T-SQL. This should not be the case.

I think this isn't directly related to cursors. (although I will look at Isomorphic suggestions).
It is just very difficult to reproduce. I was able to reproduce it with cursors, that's why I posted this example.
But I repeat, this happens with AND WITHOUT cursors (only having DMI DSRequests/DSResponses). And this happens with 5.0p and 4.1p power. I haven't tested with 3.0.

[andrerichards]

I seem to be having a similar issue then edulid. Though I'm not using a cursor.

http://forums.smartclient.com/showthread.php?t=32494