If the file.close takes a lot of time to finish (more than what it would take to write a whole new file), the server will wait until a new file is opened.
But from what I have seen on my tests TimeCompletion < TimeWrite, i.e. by the time a new file is required you will already have a new file opened.
what means this condition shouldn't happen under regular circumstances.
That's why I think this is not an issue. It would only happen if the disk was really slow. (Maybe some other application sharing the disk with JBM, and that would cause delays anyway).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173353#4173353
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173353
> The ClientUserTransaction is only a proxy to a real transaction on the server so JTS is irrelevant for normal clients
Unfortunately not. If a normal (i.e. without ORB) client is using UT to communicate to a server and that server is switched from the JTA to the JTS, the client will break. Of course that may be a bug rather than a design issue.
Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173351#4173351
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173351
"jhalliday" wrote : You missed the big one, which is: It won't work with the JTS. Since the JTS is going to be a supported option shortly, we should probably figure out what we want to do about that :-)
What do you mean? UserTransaction is JTA not JTS.
The ClientUserTransaction is only a proxy to a real transaction on the server
so JTS is irrelevant for normal clients.
If there is a transaction manager on the "client" then we use
ServerVMClientUserTransaction which is just a wrapper for that JTA implementation.
UT.begin() -> TM.begin()
etc.
Of course whether/how that "client" will propogate the TPC to the real server
maybe an issue you need to resolve, but it is irrelevant whether
the transaction was started using the UserTransaction api or some
other use of the client's TM.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173347#4173347
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173347
anonymous wrote : What happens in that case?
That could happen if you have a slow disk.
But if you have a slow disk, you would have waits on writing and waiting transactions to complete anyways. I don't think it is an issue based on the measures I've taken on the waitForAnOpenFile. I can take some meausres if you like.
There is on possible change: Start the native thread on the nextOpenFile only when the file was returned. We keep it opened but without a thread. That would save us one thread.
That means. AIO files would have three states. Opened, Active(poller thread running) and Closed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173342#4173342
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173342