Michael Wiezik

Hi Jeremy,

thanks for the response - the information you posted is very useful. However, as I mentioned above, the root cause was our own custom implementation of XAResource, which was not compatibile with the newer version of Arjuna.

I have posted this in jboss forum as well, but got frustrated by their web server response time. I'm guessing there is a New Year overload at the mo...

Anyway, I am posting the solution here in case anybody else comes across this issue:

The problem was with our custom XAResource. It reports a heuristic commit in a prepare() method. There two ways to do that from XAResource: either throw new XAException(XAException.XA_HEURCOM); or return TwoPhaseOutcome.HEURISTIC_COMMIT; . Both of them are acceptable by the older version of Arjuna and only the latter one does not cause transaction rollback in the newer Arjuna implementation.

It seems that the implementation of the jboss transaction library (called Arjuna) has been changed between jboss 3.2.0 and 5.1.0.GA:

- in Arjuna 4.2.3.SP5 (used by JBoss 3.2.0), when distributed resource reports heuristic commit, the transaction is not rolled back.
- in Arjuna 4.6.1.GA (used by JBoss 5.1.0.GA), when distributed resource reports heuristic commit, the HEURISTIC_HAZARD is being reported, which causes transaction rollback

The actual change is within the com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare() method, catch(XAException) block:

old implementation (from line 283):

/* * XA_RB*, XAER_RMERR, XAER_RMFAIL, XAER_NOTA, XAER_INVAL, or * XAER_PROTO. */ if (_rollbackOptimization) // won't have rollback called on it removeConnection(); if ((e1.errorCode == XAException.XAER_RMERR) || (e1.errorCode == XAException.XAER_RMFAIL)) return TwoPhaseOutcome.HEURISTIC_HAZARD; return TwoPhaseOutcome.PREPARE_NOTOK;


new implementation (from line 289):

/* * XA_RB*, XAER_RMERR, XAER_RMFAIL, XAER_NOTA, XAER_INVAL, or * XAER_PROTO. */ if (_rollbackOptimization) // won't have rollback called on it removeConnection(); switch (e1.errorCode) { case XAException.XAER_RMERR: case XAException.XAER_RMFAIL: case XAException.XA_RBROLLBACK: case XAException.XA_RBEND: case XAException.XA_RBCOMMFAIL: case XAException.XA_RBDEADLOCK: case XAException.XA_RBINTEGRITY: case XAException.XA_RBOTHER: case XAException.XA_RBPROTO: case XAException.XA_RBTIMEOUT: case XAException.XAER_INVAL: case XAException.XAER_PROTO: case XAException.XAER_NOTA: // resource may have arbitrarily rolled back (shouldn't, but ...) return TwoPhaseOutcome.PREPARE_NOTOK; // will not call rollback default: return TwoPhaseOutcome.HEURISTIC_HAZARD; // we're not really sure (shouldn't get here though).

Having said that, I don't understand why this change has been implemented and what is the workaround for the issue?

Hi All,

I am trying to migrate from JBoss 3.2.0 to 5.1.0GA. The application running on the server is invoking remotely EJBs deployed on yet another jboss 3.2.0. When I start JBoss 5.1.0.GA, I can see the following logs:

javax.transaction.HeuristicMixedException
javax.transaction.HeuristicMixedException
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:254)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:501)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
at org.jboss.ejb.Container.invoke(Container.java:1029)
at sun.reflect.GeneratedMethodAccessor356.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
...

13:42:41,888 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recoverin
g non-serializable XAResource < 131075, 26, 24, 49459748495454985158101574958529851985651100485850575797484954549851581015749585298519856511004858509750 >


Any clues will be appreciated. Thanks!

I just had confirmation from Sun - from now on I am happy holder of SCEA. Weehee!

Thanks all java ranchers for sharing your experience - it was very helpful.

Hmm what's next - I guess Oracle certification path...

Or maybe they sponsor SCEA because they are so desperate to find proper architecture for their ecommerce.

If anybody doubts BSCS is a real-life example, I'd suggest looking at this: http://www.bigsmokecigars.com/

Originally posted by Ivan Vrtacnik:
I have been told that using

main(String... args){}

is not a legal way to use the main method. But now I have twice seen it in unrelated sources and don't know what to think! Please help me!

Being curious, I've tried it with sun JDK and created class with method of this signature. It compiles and executes fine. Afaik, main(String... args) and main(String[] args) has exactly the same representation in byte code. It does not seem very useful though, as this method is usually not invoked from within code.

Just for curiosity, what arguments you have been told against using it?

Originally posted by Lann Lu:
Definitely this is fat client.

When we talk about "thin" client nowadays, we really means browser based client.

Cheers,
Tao

I would not agree with that, I would call rich-GUI Swing client with all business logic processed as PL/SQL still a 'thin' client. I would not call application defining a presentation logic a 'fat client'. But overally, I don't think it makes sense to argue where exactly is border between fat and thin client. On one end, you've got thin clients, classic terminals that just display output generated by mainframe server and forward all key events to it. On the other end, you've got unarguably fat clients, desktop applications, performing SQL queries / updates directly on database. But in the middle, you've got full spectrum of applications like ajax-based text editors, applets, and mentioned swing->psql clients which do not classify that easily.

You could also argue that thin clients by definition do not require updates on client-side, but again, with technologies such as Java Web Start even that classifier is sometimes ambiguous.

Hi Jeff, thanks for answering. I fully agree with component definition given by you, but I have an impression Sun SCEA part II requirements are not consistent with it. It is explicitely stated that assignee should model EJBs, servlets, jsp pages, major POJOs and important controllers as components, which brings my confusion. For me, it sounds like every class apart from Remote/Local interfaces and POJIs.

What I would like to understand is how it should be applied in a context of SCEA part II. According to definition quoted by you, I could model each major JSP page / service / entity as separate component, but I have an impression the component diagram would contain too much implementation details. I was wondering maybe it is better having one JSP component / DAO component / Entity Component / Service component with <template> stereotype. In that way, diagram would allow to define architectural-level information (e.g. jsp pages submit requests to ControllerServlet, but are isolated from services) and would be free from low-level implementation details (e.g. that AddUserAction delegates request to UserService and not to RegistrationService).

Further to the questions above:

4) should component diagram bring information about business logic (e.g. particular action depends on particular component for finalizing customer payment) or should it contain strictly infrastructural information (e.g. web action depends on service locator in order to obtain service)

5) If component referres to conrete class, should it be named after this class (e.g. CustomerEJB) or a more generic way (Customer)?

Thanks in advance for indications.

Hi all,

I have recently stuck with a trivial task - preparing component diagram. I am not confident what exactly should be modelled as component. Having speaking with professional java architects, 'component' should be high-level abstraction of system part. On the other hand, Sun assigment defines components as EJBs, Servlets, Managers or main POJOs. I have ended up creating component diagram containing almost every concrete class as component, which, after having a second look, I found ugly and fundamentally wrong.

Therefore, my questions are:

1) Should web actions be modelled as components? Or should it be one generic action component that referres to all action classes?
2) Should persistent entities be modelled as components? Or should it be one generic component that referres to all persistent entities?
3) same with DAO (assuming there's one DAO per one persistent entity class): many DAO components or one DAO component? Or should DAO be rather modelled as a port for entity component?

Any suggestions will be much appreciated.

'Thin client' is by definition client with all business logic processed on server side. If all business logic is defined in PL/SQL and client is limited to displaying obtained results, I would say it is thin client.

Thanks guys

Did SCEA this week - result is exactly what I was expecting, although I was hoping for something nearer 90%... but anyway I've passed it and I can prepare to part II.

The only section I had really low score was 'Web Tier Technologies' (37%), which again didn't supprise me as I don't have much work experience with front end. Doing SCBCD beforehand helped with other sections a lot, as well as doing mock exams from Whizlabs preparation kit (good product, guys!).

And now - part II...