| CDO - TransactionTimeout [message #490619] |
Fri, 09 October 2009 12:48  |
|
Hi,
in the redview designer i have to keep a cdoTransaction alive for some hours, because the user can change the underlying the emf model every time.
So i am creating one cdoTransaction and use it the whole time, the designer editor is opened.
But if i have not commited the transaction for about 20minutes i am getting an exception on commit. The exception tells me, that the SignalingProtocol is not active.
I have set the commitTimeout to 36000 sec, so i think it should not happen. And the protocolTimeout to NO_TIMEOUT.
I also tried to test the activity before commit with the LifecycleUtli.checkActive(). I am passing the session, transaction and protocol, but the util tells me -> active.
But by committing the transaction, the server sends a protocol not active message.
Who can i check the active state at clientside?
Are there some other attributes to set to enlarge the commitTimeout?
I also had a look at the gastro example It uses the model as a business model and i can not do the same way.
Thanks, Flo
|
|
|
| Re: CDO - TransactionTimeout [message #490660 is a reply to message #490619] |
Fri, 09 October 2009 15:19  |
|
Hi Flo,
Comments below...
Florian Pirchner schrieb:
> Hi,
>
> in the redview designer i have to keep a cdoTransaction alive for some
> hours, because the user can change the underlying the emf model every
> time.
>
> So i am creating one cdoTransaction and use it the whole time, the
> designer editor is opened.
Especially in multi-threaded scenarios I prefer a pattern with a single
global read-only view and dedicated transactions for modifications in
background jobs. But an open editor can be different.
>
> But if i have not commited the transaction for about 20minutes i am
> getting an exception on commit. The exception tells me, that the
> SignalingProtocol is not active.
Stack traces help a lot. May I see it?
>
> I have set the commitTimeout to 36000 sec, so i think it should not
> happen. And the protocolTimeout to NO_TIMEOUT.
The commit timeout is not a transaction idle timeout and the protocol
timeout is not so, either.
>
> I also tried to test the activity before commit with the
> LifecycleUtli.checkActive(). I am passing the session, transaction and
> protocol, but the util tells me -> active.
I suspect that the connection is physically terminated in your situation
after a TCP idle time. Can you try the Net4j heartbeat protocol:
http://www.google.de/#hl=de&lr=lang_de|lang_en&num=3 0&newwindow=1&ei=HlPPSrv-LIiB_Qau0vHYAg&sa=X& ;oi=spell&resnum=1&ct=result&cd=1&q=net4j+he artbeat+protocol&spell=1&fp=108405b7740ad5fb
>
> But by committing the transaction, the server sends a protocol not
> active message.
I noticed that it's very OS dependent, and possibly also JVM dependent
(?), if and how such hardware disconnects due to TCP idle timeouts are
recognized and handled. This may result in one side of the connection
*thinking* it's still active. The heartbeat protocol leads to quicker
reaction.
>
> Who can i check the active state at clientside?
You mean, checking on client-side if the server-side is inactive? There
is IMO no other means than the heartbeat protocol.
> Are there some other attributes to set to enlarge the commitTimeout?
No, and I don't think that the commit timeout is related at all.
>
> I also had a look at the gastro example It uses the model as a
> business model and i can not do the same way.
I'm not sure I understand what you mean here. Can you explain it in
different words?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.02620 seconds
] 
Search
Help
Register
Login
Home
