Hi,

Davide Mora wrote:
> 1- Is not required by ejb spec. to give access to
> transactions from the client. I'm right?
> 
> 2- UserTransactions are not currently supported by
> jBoss, rigth?
> 
> 3- If i use an ejb server that support transactions at
> client side, my ejbs/clients will be portable between
> application servers that support this feature?
> 
> 4- If and when client demarcated transactions will be
> available for jBoss?

The problem with the current transaction implementation
in jBoss is that is it based directly on the JTA spec
which is purely local. While we propagate transactions
on remote calls, these transactions only work when we
are in the same VM as the transaction originator.
So if the client is in the same VM as the server
client demarcated transactions should be OK, but if
the client is really remote a transaction started by
the client would not work on the server.

> 5- Where i can find more details/example about the
> "facade pattern with a stateless session bean"
> approach suggested by Dan OConnor?

While this is really a workaround for not being able
to start a transaction on the client, is is a good idea
to use this whenever possible to avoid a client crash
giving transaction timeouts and (horrors) heuristic
transaction decisions.

It goes as:
Instead of having the client do the transaction, it
delegates its work to a stateless session bean by
calling a method on it. All data needed by the
transaction is sent to the stateless bean and all
data that needs to be returned are returned when
the stateless bean method returns. In the stateless
session bean descriptor you declare that the container
should invoke the method with a new transaction and
commit when returning (RequiresNew or Required if you
always call the method without a transaction context).

The advantage of this is that the server keeps on
working until the transaction is finished even if the
client crashes. So other clients will not have to wait
for locks to be released until the transaction times
out.


Best Regards,

Ole Husgaard.


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to