An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.
An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).
XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.
Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.
The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.
In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item).
For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on "Java JTA XA transaction". Fonte: http://www.theserverside.com/discussions/thread/21385.html
<serverxmlns="urn:jboss:domain:2.2"><extensions>
....
</extensions>
// Adicione as linhas abaixo para resolver o problema
<system-properties><propertyname="java.util.Arrays.useLegacyMergeSort"value="true"/></system-properties></server>
Segue abaixo algumas considerações acerca da API JTA e de como EJB3 suporta transações declarativamente.
Normalmente as transações em aplicações são controladas em nível de métodos de negócio. Para se declarar que se está sendo utilizada alguma transação deve se utilizar a anotação @TransactionAttribute.
Por padrão a transação utiliza a estratégia REQUIRED, que significa que se o método do serviço não possuir alguma transação, uma será criada, e se já possuir uma transação esta será aproveitada. Esta é a estratégia que deve ser utilizada na maior parte dos casos uma vez que é bem lógica.
O que esta estratégia quer dizer resumidamente? Quando você estiver em um contexto de transação e caso ocorra alguma exceção do tipo Runtime ou exceção com a anotação @ApplicationException(rollback=true), deve ser dado o rollback na base de dados. Com esta estratégia padrão sempre será dado o rollback da transação mais externa, o que na maioria dos casos faz todo sentido.
Outras estratégias são:
SUPPORTS – Não cria nenhuma transação, mas se já existir alguma ela será utilizada.
MANDATORY – Requer que quem chamou o método tenha criado uma transação.
NEVER – Proíbe que quem chamou o método tenha iniciado uma transação.
REQUIRESNEW – Sempre começa uma nova transação, suspendendo a antiga existente.
NOTSUPPORTED – Suspende qualquer transação ativa.
Como padrão, pode-se anotar toda a classe com a anotação @TransactionAttribute, o que determina que todos os métodos da classe utilizam transação e com a estratégia REQUIRED. Caso exista algum método que deva usar outra estratégia basta sobrescrever a estratégia usando acima do método alguma das anotações abaixo:
@ECHO OFF
REM DATA E HORA SEPARADA POR PONTO(.)
REM DIA(DD) MES(MM) ANO(AAAA) HORA(HH) MINUTO(MM) SEGUNDO(SS)
Set TODAY="%DATE:~0,2%.%DATE:~3,2%.%DATE:~-4%" %time:~0,2%.%time:~3,2%.%time:~6,2%
ECHO.
REM -mx9 = MAXIMA COMPRESSAO
7za a -tzip "C:\TESTE_%TODAY%.zip" "C:\TESTE" -mx9
ECHO.
PAUSE
SELECT username, profile FROM dba_users
WHERE username in ('SYSTEM', 'SEUUSUARIO');
3) VERIFICAR O LIMITE DE TEMPO DA SENHA
select resource_type, limit
from dba_profiles
where profile='DEFAULT'
and resource_name = 'PASSWORD_LIFE_TIME';
4) REMOVER O LIMITE DE TEMPO DA SENHA
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;
5) DESBLOQUEAR USUARIO
ALTER USER SEUUSUARIO IDENTIFIED BY SENHA ACCOUNT UNLOCK;
1) Abrir Prompt de Comando
2) Navegar até o diretório do WildFly\bin\Service
3) Digitar o comando: service install
4) O serviço deverá ser configurado manualmente para inicio automático (services.msc)
WildFly 10
1) Abra o diretóro WildFly\docs\contrib\scripts\service.
2) Copie os arquivos para o diretório WildFly\bin.
3) Digitar o comando: service install
4) O serviço deverá ser configurado manualmente para inicio automático (services.msc)
Cause:
There is an incorrect ORDER BY item. The query is a SELECT DISTINCT query with an ORDER BY clause. In this context, all ORDER BY items must be constants, SELECT list expressions, or expressions whose operands are constants or SELECT list expressions.
Solução: adicionar um join e fazer a ordem através dele.
TypedQuery<CheckList> q = em.createQuery("select distinct"
+ " checkList "
+ " from " + CheckList.class.getName() + " checkList"
+ " left join fetch checkList.usuarioResponsavel usuarioResponsavel"
+ " where"
+ " checkList.dataCadastro = :dataPesquisa "
+ " order by usuarioResponsavel.nome", CheckList.class);
A exceção ocorre durante a manipulação de uma grande quantidade de informações, que acaba consumindo muito tempo e excede o default-timeout de 5 minutos.
Solução:
Adicionar a linha abaixo no standalone.xml do WildFly/JBoss,
The @Asynchronous annotation was introduced in EJB 3.1 as a simple way of creating asynchronous processing.
Every time a method annotated @Asynchronous is invoked by anyone it will immediately return regardless of how long the method actually takes. Each invocation returns a Future object that essentially starts out empty and will later have its value filled in by the container when the related method call actually completes. Returning a Future object is not required and @Asynchronous methods can of course return void.
Example
Here, in JobProcessorTest,
finalFuture<String> red = processor.addJob("red"); proceeds to the next statement,
without waiting for the addJob() method to complete. And later we could ask for the result using the Future<?>.get() method like
assertEquals("blue", blue.get());
It waits for the processing to complete (if its not completed already) and gets the result. If you did not care about the result, you could simply have your asynchronous method as a void method.
A Future represents the result of an asynchronous computation. Methods are provided to check if the computation is complete, to wait for its completion, and to retrieve the result of the computation. The result can only be retrieved using method get when the computation has completed, blocking if necessary until it is ready. Cancellation is performed by the cancel method. Additional methods are provided to determine if the task completed normally or was cancelled. Once a computation has completed, the computation cannot be cancelled. If you would like to use a Future for the sake of cancellability but not provide a usable result, you can declare types of the form Future and return null as a result of the underlying task
The code
@SingletonpublicclassJobProcessor{@Asynchronous@Lock(READ)@AccessTimeout(-1)publicFuture<String> addJob(String jobName){// Pretend this job takes a while
doSomeHeavyLifting();// Return our resultreturnnewAsyncResult<String>(jobName);}privatevoid doSomeHeavyLifting(){try{Thread.sleep(SECONDS.toMillis(10));}catch(InterruptedException e){Thread.interrupted();thrownewIllegalStateException(e);}}}
Test
publicclassJobProcessorTestextendsTestCase{publicvoid test()throwsException{finalContext context =EJBContainer.createEJBContainer().getContext();finalJobProcessor processor =(JobProcessor) context.lookup("java:global/async-methods/JobProcessor");finallong start =System.nanoTime();// Queue up a bunch of workfinalFuture<String> red = processor.addJob("red");finalFuture<String> orange = processor.addJob("orange");finalFuture<String> yellow = processor.addJob("yellow");finalFuture<String> green = processor.addJob("green");finalFuture<String> blue = processor.addJob("blue");finalFuture<String> violet = processor.addJob("violet");// Wait for the result -- 1 minute worth of work
assertEquals("blue", blue.get());
assertEquals("orange", orange.get());
assertEquals("green", green.get());
assertEquals("red", red.get());
assertEquals("yellow", yellow.get());
assertEquals("violet", violet.get());// How long did it take?finallong total =TimeUnit.NANOSECONDS.toSeconds(System.nanoTime()- start);// Execution should be around 9 - 21 seconds// The execution time depends on the number of threads available for asynchronous execution.// In the best case it is 10s plus some minimal processing time.
assertTrue("Expected > 9 but was: "+ total, total >9);
assertTrue("Expected < 21 but was: "+ total, total <21);}}
Running
-------------------------------------------------------
T E S T S
-------------------------------------------------------Running org.superbiz.async.JobProcessorTestApacheOpenEJB4.0.0-SNAPSHOT build:20110801-04:02
http://tomee.apache.org/
INFO - openejb.home = G:\Workspace\fullproject\openejb3\examples\async-methods
INFO - openejb.base= G:\Workspace\fullproject\openejb3\examples\async-methods
INFO -Using'javax.ejb.embeddable.EJBContainer=true'
INFO -ConfiguringService(id=DefaultSecurityService, type=SecurityService, provider-id=DefaultSecurityService)
INFO -ConfiguringService(id=DefaultTransactionManager, type=TransactionManager, provider-id=DefaultTransactionManager)
INFO -FoundEjbModulein classpath: g:\Workspace\fullproject\openejb3\examples\async-methods\target\classes
INFO -Beginning load: g:\Workspace\fullproject\openejb3\examples\async-methods\target\classes
INFO -Configuring enterprise application: g:\Workspace\fullproject\openejb3\examples\async-methods
INFO -ConfiguringService(id=DefaultSingletonContainer, type=Container, provider-id=DefaultSingletonContainer)
INFO -Auto-creating a container for bean JobProcessor:Container(type=SINGLETON, id=DefaultSingletonContainer)
INFO -ConfiguringService(id=DefaultManagedContainer, type=Container, provider-id=DefaultManagedContainer)
INFO -Auto-creating a container for bean org.superbiz.async.JobProcessorTest:Container(type=MANAGED, id=DefaultManagedContainer)
INFO -Enterprise application "g:\Workspace\fullproject\openejb3\examples\async-methods" loaded.
INFO -Assembling app: g:\Workspace\fullproject\openejb3\examples\async-methods
INFO -Jndi(name="java:global/async-methods/JobProcessor!org.superbiz.async.JobProcessor")
INFO -Jndi(name="java:global/async-methods/JobProcessor")
INFO -Jndi(name="java:global/EjbModule100568296/org.superbiz.async.JobProcessorTest!org.superbiz.async.JobProcessorTest")
INFO -Jndi(name="java:global/EjbModule100568296/org.superbiz.async.JobProcessorTest")
INFO -CreatedEjb(deployment-id=org.superbiz.async.JobProcessorTest, ejb-name=org.superbiz.async.JobProcessorTest, container=DefaultManagedContainer)
INFO -CreatedEjb(deployment-id=JobProcessor, ejb-name=JobProcessor, container=DefaultSingletonContainer)
INFO -StartedEjb(deployment-id=org.superbiz.async.JobProcessorTest, ejb-name=org.superbiz.async.JobProcessorTest, container=DefaultManagedContainer)
INFO -StartedEjb(deployment-id=JobProcessor, ejb-name=JobProcessor, container=DefaultSingletonContainer)
INFO -DeployedApplication(path=g:\Workspace\fullproject\openejb3\examples\async-methods)Tests run:1,Failures:0,Errors:0,Skipped:0,Time elapsed:13.305 sec
Results:Tests run:1,Failures:0,Errors:0,Skipped:0[INFO]------------------------------------------------------------------------[INFO] BUILD SUCCESS
[INFO]------------------------------------------------------------------------[INFO]Total time:21.097s[INFO]Finished at:WedAug0322:48:26 IST 2011[INFO]FinalMemory:13M/145M[INFO]------------------------------------------------------------------------
How it works under the covers
Under the covers what makes this work is:
The JobProcessor the caller sees is not actually an instance of JobProcessor. Rather it's a subclass or proxy that has all the methods overridden. Methods that are supposed to be asynchronous are handled differently.
Calls to an asynchronous method simply result in a Runnable being created that wraps the method and parameters you gave. This runnable is given to an Executor which is simply a work queue attached to a thread pool.
After adding the work to the queue, the proxied version of the method returns an implementation of Future that is linked to the Runnable which is now waiting on the queue.
When the Runnable finally executes the method on the realJobProcessor instance, it will take the return value and set it into the Future making it available to the caller.
Important to note that the AsyncResult object the JobProcessor returns is not the same Future object the caller is holding. It would have been neat if the real JobProcessor could just return String and the caller's version of JobProcessor could return Future<String>, but we didn't see any way to do that without adding more complexity. So the AsyncResult is a simple wrapper object. The container will pull the String out, throw the AsyncResult away, then put the String in the realFuture that the caller is holding.
To get progress along the way, simply pass a thread-safe object like AtomicInteger to the @Asynchronous method and have the bean code periodically update it with the percent complete.
Related Examples
For complex asynchronous processing, JavaEE's answer is @MessageDrivenBean. Have a look at the simple-mdb example
