JBoss updates: Cache, Eclipse IDE, Transactions

Discussions

News: JBoss updates: Cache, Eclipse IDE, Transactions

  1. JBoss has recently gone through a set of releases: JBoss Cache (with an Eclipse plugin), and JBoss Transactions, which is the open source release of the Arjuna transaction engine. In addition, rumours abound yet again of JBoss acquisition and/or JBoss IPO - which one is valid is nearly impossible to tell, as usual.

    JBoss Cache has undergone a number of changes: "optimistic locking, invalidation, the ability to configure more than one cache loader, a new programmatic Option API to allow for configuration overrides on a per invocation basis, a few new remote cache loaders that allow you to use the a dedicated remote host with a lot of physical RAM as a cache loader, and plenty of overall performance enhancements, particularly around cache loaders," according to Manik Surtani's blog posting about the release, "JBoss Cache 1.3.0.GA "Wasabi" released."

    The accompanying Cache implementation in the Eclipse IDE (bundled with JBoss IDE) allows connecting to the remote cache instance in the JBoss Application Server via JMX, viewing content of the cache, and viewing cache graph content of the cache via TreeCacheAOP. However, this is based on a prior version of JBoss Cache; updates to the new release should be coming soon.

    In other news about JBoss, it's been suggested (again) that an acquisition is in the works, although a likely buyer hasn't been put forth. (See "JBoss makes IPO plans" from Builder UK, by Martin Lamonica, for a representative example.) At the same time, rumours of a JBoss IPO have resurfaced, again without much verification; both of these are rumours and have not been substantiated, so it's nearly impossible to gauge which one is valid (or if either one is valid in the first place). However, it's safe to say that barring a very strange circumstance, JBoss is alive and well, and an acquisition or an IPO would only serve to strengthen the company and, by extension, the product, despite growing competition from Glassfish, JoNaS, and Geronimo, all free J2EE application servers.

    Threaded Messages (41)

  2. JBoss updates[ Go to top ]

    Apparently they've also fixed a bug recently, and had their office kitchen re-fitted.

    Is this a slow news day ?
  3. Focus lost on original posting[ Go to top ]

    Try to focus on what really is news - a flurry of major new releases by JBoss, including:

    * JBoss Messaging 1.0
    * JBoss Transactions 4.2
    * JBoss Cache 1.3.0
    * JBoss Rules/Drools 3.0
    * jBPM 3.1

    Much more detailed info here: http://jboss.org/jbossBlog/blog/

    I'm surprised each of these didn't get their own TSS posting, to be honest.
  4. JBoss updates[ Go to top ]

    Apparently they've also fixed a bug recently, and had their office kitchen re-fitted.Is this a slow news day ?

    Do you code for a living? Are you clueless to the innovation JBoss is kicking out with JBPM, Seam and other things?

    I'd rather hear about bijection, JSF innovations and other stuff coming from JBoss than the latest bloatware from IBM Websphere 12.
  5. JBoss updates[ Go to top ]

    Do you code for a living?

    Yes I do. Why ? Do you need some of your bugs fixing ?

    This subject of this thread is way to broad and as such is unlikely to lead to a useful or informative thread. It looks like it's just an encouragment to JBoss luvies so re-gurgitate their incestuously warm feelings toward everything JBossy.
  6. JBoss updates[ Go to top ]

    This subject of this thread is way to broad and as such is unlikely to lead to a useful or informative thread.

    This is true. Each of the recent software announcements by JBoss should be the subject of a separate thread.

    See, for instance, the thread "SwiftMQ 6.0 with High/Continuous Availability Released":

    http://www.theserverside.com/news/reply.tss?message_id=205517

    There is some technical discussion on that thread. This is a good thing. If the new releases of JBoss Messaging, JBoss Transactions, JBoss Cache, JBoss Rules, jBPM and JBoss Application Server had similar threads, there would be more room for good techical discussion.

    Then there could be also a thread on JBoss acquisition or IPO rumours, for those who care. And perhaps another one entitled "JBoss Lovers X JBoss Haters -- This Is The Place", to attract all the folks who want to engage in that sort of discussion and hopefully keep them away from the technical threads.
  7. JBoss updates[ Go to top ]

    See, for instance, the thread "SwiftMQ 6.0 with High/Continuous Availability Released":
    http://www.theserverside.com/news/reply.tss?message_id=205517

    Oops, I pasted the wrong link. The correct one is

    http://www.theserverside.com/news/thread.tss?thread_id=39745
  8. JBoss Transactions is big[ Go to top ]

    The JBoss Transactions is big news, and can't believe it didn't get more attention here at TSS. For years, JBoss detractors like Mike Spille have been trashing JBoss because it lacks a TM with recovery....Well, now we do, and it is open source. Not only that, but a full distributed transaction manager, WS-TX, and usable outside of jboss AS, ad more. Pretty much makes JOTM look like a toy now. Now finally, Java OSS has a mature fully-featured TM that is usable in a variety of environments.
  9. JBoss Transactions is big[ Go to top ]

    Indeed. JBoss Messaging as well.

    Regards,
    Horia Muntean
  10. JBoss Transactions is big ?[ Go to top ]

    what is special about it that is not in a 1k lines TM? can't see the plus to what is defined in the standard. please outline.
  11. JBoss Transactions is big ?[ Go to top ]

    what is special about it that is not in a 1k lines TM? can't see the plus to what is defined in the standard. please outline.

    Too much to go into a lot of detail here, but check out this for an indepth description.

    Mark.
  12. JBoss Transactions is big[ Go to top ]

    The JBoss Transactions is big news, and can't believe it didn't get more attention here at TSS. For years, JBoss detractors like Mike Spille have been trashing JBoss because it lacks a TM with recovery....Well, now we do, and it is open source. Not only that, but a full distributed transaction manager, WS-TX, and usable outside of jboss AS, ad more. Pretty much makes JOTM look like a toy now. Now finally, Java OSS has a mature fully-featured TM that is usable in a variety of environments.

    It's a relief, definitely.

    How much did it cost?

    Guglielmo
  13. bo[ Go to top ]

    Why the need for a seperate process, the Recovery Manager? Do you need IP failover and dual ported disks/SAN for TM recovery if the box fails?

    Thanks
    Billy
    (IBM)
  14. bo[ Go to top ]

    Why the need for a seperate process, the Recovery Manager? Do you need IP failover and dual ported disks/SAN for TM recovery if the box fails?ThanksBilly(IBM)

    Maybe it's not pure Java?
  15. bo[ Go to top ]

    Why the need for a seperate process, the Recovery Manager? Do you need IP failover and dual ported disks/SAN for TM recovery if the box fails?ThanksBilly(IBM)
    Maybe it's not pure Java?

    Eh, no. As it says here, it's pure Java (and was the world's first pure Java transaction service implementation).

    Mark.
  16. bo[ Go to top ]

    Why the need for a seperate process, the Recovery Manager? Do you need IP failover and dual ported disks/SAN for TM recovery if the box fails?ThanksBilly(IBM)

    You don't need to run it as a separate process. Although it is referred to as a daemon (and can be run as an OS process), it runs just as well embedded in the same process/VM as the transaction coordinator.

    You can replicate your coordinator logs if you so desire, but you don't need IP failover or dual ported disks. We were doing high availability transactions with COTS back in 1994 (http://www.cs.ncl.ac.uk/research/pubs/books/abstract.php?id=45). Actually we had it back in 1990, but this is the first realworld application.

    Mark.
  17. JBoss Transactions[ Go to top ]

    So I can use this with Spring. I'd like to be able to plug it (JBoss Transactions) into Spring and apply it to DAO objects.

    Of course, I would never use the crap fest you call EJB3.

    It is broken beyond belief. AOP in EJB3 has no concept of pointcuts and the method interceptors are tied to actual EJBs.

    Also, could you change Seam to work with Spring b/c again EJB3 is Spring's retarded cousin and I have no use for it.

    I actually like a lot of JBoss products and ideas. Just please make them easy to work with in Spring.

    Thanks.

    http://www.jroller.com/page/killjoy?entry=boycott_ejb3
  18. JBoss Transactions is big[ Go to top ]

    For years, JBoss detractors like Mike Spille have been trashing JBoss because it lacks a TM with recovery....Well, now we do, and it is open source.

    Are you saying that Mike was RIGHT all along until now? When was it? A couple of years back? And I thought JBoss AS was entreprise graded all the way back.
  19. JBoss Transactions is big[ Go to top ]

    Pretty much makes JOTM look like a toy now.
    Wow. What an achievement ! Do you guys code there at JBOSS ?

    Now finally, Java OSS has a mature fully-featured TM that is usable in a variety of environments.

    You mean the second one right ? Cause Geronimo is having this since some time now. And I am sure I have to wait a little longer until I see Spring integration for it right ? Cause it comes from JBOSS and when you need a product from JBOSS you can't get away w/o getting a bunch of others including their kickass Jboss AS, right ?

    Java OSS is not you anymore Bill. Apache is doing fine. Codehaus is now the source of most innovation in the Java OS space. JBOSS is known for two things: their arrogance and their business model.
  20. JBoss Transactions is big[ Go to top ]

    JBOSS is known for two things: their arrogance and their business model.

    And BTW. Talking about Mike Spille who's been a JBoss detractor. You still could learn bunches from him isn't it ? :-))
  21. A bit of perspective[ Go to top ]

    I went back and read the discussion on the jboss road map in 1/2004. We all knew if wasn't going to take 3 months:

    http://www.theserverside.com/news/thread.tss?thread_id=23090#105781

    I am pasting this (from Mike) below just because it's so well put:
    On general support of XA transactions by the container, once again we have a transaction system with no transaction log. Cycle JBoss with in-flight transactions for any reason, and those in-doubt threads locking up big pieces of your database will just hang there 'till the universe dies from heat death.
  22. JBoss Transactions is big[ Go to top ]

    Cause Geronimo is having this since some time now.

    I'm not one for petty My-PC-is-better-than-your-PC arguments, so this purely an objective set of statements to set the record straight.

    Firstly, Arjuna has been integrated with JBossAS for quite a while.

    Secondly, there are always going to be differences of opinion on the right tool for the right job, but please let's just keep this on a technical (and amicable) basis.

    Thanks,

    Mark.
  23. More than just the AS[ Go to top ]

    Cause it comes from JBOSS and when you need a product from JBOSS you can't get away w/o getting a bunch of others including their kickass Jboss AS, right

    Dorel, as ever I'll ignore your usual obsessive/tragic attacks on JBoss and just address the pure factual point:

    All but one of our JEMS projects - and several other newer projects that are not yet labelled as part of the JEMS suite - runs outside of JBoss Application Server and can therefore be used in any Java environment.

    This includes:

    * Hibernate
    * jBPM
    * JBoss Cache
    * JBoss Transactions
    * JBoss Rules (Drools)
    * JBoss Messaging
    * JBoss EJB 3.0
    * Seam
    * JBoss Microcontainer
      - including JBoss JCA, JBoss JTA
    * JGroups
    * NHibernate
    * JBoss AOP
    * JBoss Remoting
    * JBoss Web

    AFAIK, the only significant project we have that *doesnt* run outside of JBoss AS is JBoss Portal - and we would like to fix that. (I'm not sure about JBoss Web Services, perhaps it is also tied to the AS.)

    So, even though your hero Mike Spille confidently predicted back in 2003 that the projects that joined JBoss would inevitably become tied to JBoss AS:

    http://www.theserverside.com/news/thread.tss?thread_id=21482

    (Ah, now that was a fun trip down memory lane, wasn't it!) Well, it turns out that three years later we're still waiting for this to happen.

    JBoss AS is indeed a totally "kickass" application server, which is why so many large organizations are adopting it over the alternatives. But JBoss the organization is much bigger than JBoss the application server. We have customers running our products on many different platforms including many on WebSphere, WebLogic, plain Tomcat, etc.

    You mean the second one right ? Cause Geronimo is having this since some time now.

    In fairness, Bill used the words "mature fully-featured TM". Certainly there have been other open source TMs out there, but none are remotely comparable to this technology that came originally from Arjuna.

    And yes, you can use it outside of JBoss AS :-)
  24. More than just the AS[ Go to top ]

    Dorel, as ever I'll ignore your usual obsessive/tragic attacks on JBoss...

    No Gavin, if you will ever read exactly what I am saying you'll see that I am mostly a critique of JBOSS's organization/people "We are the masters of the Java OS world, all others are children with broken toys in their hands".
    All but one of our JEMS projects - and several other newer projects that are not yet labelled as part of the JEMS suite - runs outside of JBoss Application Server and can therefore be used in any Java environment.

    That is excellent news, then you'll have to fight the current perception of 'Jboss is the huge kickass monolith every company chooses to replace their 10.000$/processor license app server'
    So, even though your hero Mike Spille ...
    I rest my case here I don't want to get Mike involved on a personal ground w/o him knowing it. I do not know him personally and he's not my hero, I just know that he's a very strong tech guy. And I am not interested in anything else than tech on this or any other java web site/ forum.
    But JBoss the organization is much bigger than JBoss the application server. We have customers running our products on many different platforms including many on WebSphere, WebLogic, plain Tomcat, etc.

    As a side joke ;-) I know now why the bileboy calls you Gavin Fleury.
    And yes, you can use it outside of JBoss AS :-)

    Excellent news again. Java OS has only to gain from all these things.

    But back again to my problem. Actually I do not have such strong technical skills to compare your TM to Geronimo's TM, if you say it's better then that still remains to be proved. Maybe some Geronimo guru can argue why Geronimo's TM couldn't compete with yours and if it cannot then why don't they use yours since it's OS software :-D.

    What I don not agree with is this:

    From Bill:
    Pretty much makes JOTM look like a toy now
    From you:
    In fairness, Bill used the words "mature fully-featured TM".

    Now what bothers me is the atitude. You simply cannot dismiss other people's work as they were all the time wrong and you are the father of all knowledge. Don't get me wrong, you've changed the entire Java(not only OS) landscape through your product and your your vision and I respect you for that. But you just can't dismiss other's OS efforts.

    And now the personal reason for my criticism to JBOSS people:

    I cannot forget nor ever forgive the astroturfing thing. It is simply lowlife to pretend you're somebody else and throw shit in competition's face just to put your product in a good light. It is simply a thing that I cannot get over it now or ever. You should know that a good product will impose itself in the market through it's quality and it's feature set, no need to push it by bashing others. When they released those broken benchmarks claiming some competitor of Hibernate just perform much faster, how did you feel ? And that's nothing compared to the astroturfing thing.

    Now you know. And you'll know also that I will not reply on any of these matters anymore because I do not want to highjack the thread and make it another irrelevant from the tech point of view thread. Anything I wanted to respond is not of technical nature.

    However thanks for all positive things that you've underlined in your reply. Just don't get too much Fleury in your replies :-)).
  25. JBoss Transactions is big[ Go to top ]

    Does it (still) support multi-threaded transactions? I think Arjuna did.

    regards,

    Messi
  26. JBoss Transactions is big[ Go to top ]

    Does it (still) support multi-threaded transactions? I think Arjuna did.regards,Messi

    Yes. Multiple threads in the scope of the same transaction, and multiple threads in the same VM within their own (or shared) transaction.

    Mark.
  27. I suppose the usual way to maintain txn context is via ThreadLocal. Just for curiosity, how do you maintain cross-thread txn context? Also, what does the spec opine about this?
  28. I suppose the usual way to maintain txn context is via ThreadLocal. Just for curiosity, how do you maintain cross-thread txn context? Also, what does the spec opine about this?

    Not sure what you mean exactly, but the system maintains an association of thread-to-transaction, so that a thread can always determine which transaction it is within, and a transaction can always determine which threads it is scoping.

    The specifications don't say how you do this. They only say that you need to (and sometimes in a fairly cryptic manner).

    Mark.
  29. BEA Weblogic and open source[ Go to top ]

    One of the slimiest things I have seen is from BEA Weblogic. 4 years ago they wrote a 'research paper' about the PERILS OF OPEN SOURCE. We were using JBoss and my boss was concerned. I wasted a whole bunch of time explaining how this was b.s. and how Weblogic is actually starting to use a lot of open source. So no one in the vendor space is an angel.
  30. BEA Weblogic and open source[ Go to top ]

    One of the slimiest things I have seen is from BEA Weblogic. 4 years ago they wrote a 'research paper' about the PERILS OF OPEN SOURCE. We were using JBoss and my boss was concerned. I wasted a whole bunch of time explaining how this was b.s. and how Weblogic is actually starting to use a lot of open source. So no one in the vendor space is an angel.

    Dude, you should see some of IBM's anti-JBoss material that has been passed to us by customers. Amazingly dishonest stuff.

    And then there's their latest public FUD-strategy: "JBoss is not open source in spirit". Huh? Well ok ... makes sense cos like ... IBM is not open source in *fact*.

    It's wonderful to know that IBM feels confident to define the "spirit" of open source for us. And it's great to be lectured on that by a guy who has never written a line of OSS in his life.

    So, yeah, the "astroturfing" stuff was a lowpoint for this company (actually, "astroturfing" is the wrong term, since no-one was posing as satisfied customers saying how great our products were - they were merely posting their honestly held private opinions anonymously). And of course this company will never ever ever be forgiven for a mistake made 3 years ago, even though most of the people who worked for the company then, and almost everyone who works for the company now, was not involved. And of course I don't expect our commerical competitors to be held to the same high standard that JBoss is. Why? Because people rightly understand that there is an *idealism* in open source, and expect better of us...
  31. Cargo Cult OSS[ Go to top ]

    See Feynman's .
    'm talking about a specific, extra type of integrity that is not lying, but bending over backwards to show how you're maybe wrong, that you ought to have when acting as a scientist. And this is our responsibility as scientists, certainly to other scientists, and I think to laymen.
  32. Cargo Cult OSS[ Go to top ]

    See Feynman's .
    'm talking about a specific, extra type of integrity that is not lying, but bending over backwards to show how you're maybe wrong, that you ought to have when acting as a scientist. And this is our responsibility as scientists, certainly to other scientists, and I think to laymen.

    The link didn't come out. It's here:

    http://www.physics.brocku.ca/etc/cargo_cult_science.html

    Ask yourself: why is the JBoss source accessible to all? Is it free as in "free beer" or as in "free speech". In my opinion, it would not make much difference if the jboss source were closed but the the license were free.

    Guglielmo
  33. say I do userTransaction.begin() in the current thread (which I will call the "master thread"), next spawn 5 threads and perform work that touches resource managers in each of the child threads and then do userTransaction.commit() in the master thread. The question is: will the work done in each of the 5 child threads be all part of the same transaction started by the master thread? If not, is there a way to do this and if so, is this a feature of Arjuna only (left to the vendor by the spec)?
  34. say I do userTransaction.begin() in the current thread (which I will call the "master thread"), next spawn 5 threads and perform work that touches resource managers in each of the child threads and then do userTransaction.commit() in the master thread. The question is: will the work done in each of the 5 child threads be all part of the same transaction started by the master thread? If not, is there a way to do this and if so, is this a feature of Arjuna only (left to the vendor by the spec)?

    The specs don't say anything about how to manage thread-to-transaction association in terms of implementation (e.g. ThreadLocal), because that's an implementation (and language) choice.. What they will say (and I paraphrase), is that: if you want the work done by a thread to be within the scope of a transaction that is already running, then you need to do make sure that thread is associated with the transaction.

    There are several ways in which you can do this, but if you are interested in only working within the bounds of the specifications (e.g., JTA or OTS), then you could use TransactionManager.resume (in JTA), or Current.resume (in the OTS); both of which take a reference to a transaction and may associate it with the calling thread. However, it is then up to the underlying implementation to determine whether this is something it can support. Implementations that don't support multiple threads in the scope of the same transaction are free to throw an exception at this stage and refuse the association attempt. None of the specifications mandate multi-threaded transaction capabilities, so this is a perfectly legitimate thing for them to do.

    Mark.
  35. This seems contradictory to Billy Newport's comments here: http://www.theserverside.com/news/thread.tss?thread_id=35626#180329

    "..Sharing transaction between threads isn't possible and even if it was would be a nightmare to support. It would also mean things we'd assume are single threaded and don't need synchronization would now need synchronization and slow down.

    Camerons interpretation is absolutely right. Different thread, different transaction...."

    You might need to read that thread a bit to understand the context. It seems to indicate that doing this kind of thing is difficult. Of course, I might be interpreting Billy/Cameron's comments completely incorrectly or maybe I am missing something?
  36. Cameron was responding to this:
    I was playing around with this a while back and I think, in WebSphere, if you pass the JTA userTxn to child threads and use it in the child threads, the work performed in the child threads is performed in the same context as the parent thread. So you are not forced to do your work sequentially.

    I don't think the UserTransaction object can be passed around, but that's an api issue, not a transaction issue. I don't know if JTA restricts each tx to one thread in a single vm - it might do so to keep it simple for system developers - but it doesn't _have_ to do it. So in principle jboss can support and maybe the spec can be relaxed later.

    However what Billy was saying is that the assumption of 1-tx-per-thread may have been used all over an app server, so just because the TM supports it doesn't mean that you can start doing multi-threaded transactions. Somebody who knows all the various subsystems needs to do a code review and check that it won't break things.

    Guglielmo
  37. Cameron was responding to this:
    I was playing around with this a while back and I think, in WebSphere, if you pass the JTA userTxn to child threads and use it in the child threads, the work performed in the child threads is performed in the same context as the parent thread. So you are not forced to do your work sequentially.
    I don't think the UserTransaction object can be passed around, but that's an api issue, not a transaction issue. I don't know if JTA restricts each tx to one thread in a single vm - it might do so to keep it simple for system developers - but it doesn't _have_ to do it.

    UserTransaction maintains information on transactions on a per thread basis. I've seen implementations that provide a single instance of UT per thread, or ones where you have a singleton in the process and it multiplexes the calls on behalf of all threads. Same ultimate behaviour.
    So in principle jboss can support and maybe the spec can be relaxed later.

    Nothing wrong with the specs. They allow multiple threads in the same transaction. Or maybe you're referring to a different issue?
    However what Billy was saying is that the assumption of 1-tx-per-thread may have been used all over an app server, so just because the TM supports it doesn't mean that you can start doing multi-threaded transactions. Somebody who knows all the various subsystems needs to do a code review and check that it won't break things.Guglielmo

    If you just throw threads at a transaction and hope it'll work, then you're right. However, if that transaction system supports checked transactions (referenced in one of my earlier replies), then this capability is intended to ensure data integrity is not compromised. There are situations where you may find some work blocks the transaction completion until it's completed. In these cases, an evaluation of the impact of threading and transactions, along the lines you mention, would be advisable.

    Mark.
  38. Well, I asked for the multi-threaded transactions b/c I need them and AFAIK JTA doesn't support them (explicitely?) - Cannot find it now but I somehow thought that the XAResource (implementations) have problems with this.
    Singel threaded transactions also seem to be dictated if the UserTransaction interface is used, see JavaDocs "(Starts/commits/rolls back) transaction...associated with the current thread".

    regards,

    Messi
  39. Well, I asked for the multi-threaded transactions b/c I need them and AFAIK JTA doesn't support them (explicitely?)

    Not true. JTA, as with pretty much any standard, is written in a way to allow its mapping to a range of implementations: yes, those vagueries in the text aren't always bugs! The JTA does not explicitly rule out multi-threaded transaction implementations, and combined with the fact that it's meant to be mapped to the JTS, which is a language mapping of the OMG's OTS, which I also helped develop, means that you can have such implementations.
    - Cannot find it now but I somehow thought that the XAResource (implementations) have problems with this.

    Not sure what problem you perceive here, but as I've said before, checked transactions help. In fact, the default implementation of checking that is recommended by the OTS, is the one used in the X/Open XA specification, on which JTA is based.
    Singel threaded transactions also seem to be dictated if the UserTransaction interface is used, see JavaDocs "(Starts/commits/rolls back) transaction...associated with the current thread".regards,Messi

    No, that's incorrect. What this means is that the UT and TM interfaces allow a thread to start and end a transaction, but they don't say that only that thread can be involved in the transaction. If you check out the text of resume, for example, it does not say that the transaction reference has to be one which was previously associated with the invoking thread. The implementation is free to impose that restriction if it needs to (and would then throw the InvalidTransactionException). It's the same as with the OTS, where Current::resume would be used in this case.

    So, if you need multiple threads within the scope of the same transaction, the standards do allow for it. You just need to find an implementation. And as someone else mentioned before JBoss Transactions is one such implementation.

    Mark.
  40. Thanks for your explanations. Always nice to hear straight from the expert and creator. Great to know JBoss Transactions supports "multiple threads within the scope of the same transaction".

    Sorry to digress away from JBoss Transactions, but does WebSphere support this functionality? Anybody who knows care to comment on this?
  41. Hi everyone, We have developed our own framework based on the following design patterns and open source frameworks. 1) DAO -> Factory pattern using JDBC Connection Implementation - > Apache DBCP Pooling 2) Business layer - Factory POJO implementation Business remoting - JBOSS Remoting using socket Remoting API. 3) Client -> Aspect oriented framework (Cocoon) using stylesheets. Servlet = Cocoon View = XSLT generated pages 4) Supporting Services - Authentication -> Implemented within the application. Authorization - Implemented within the application. Transaction Management - Not implemented - TBD Event Management using Messaing (Apache MQ?) - TBD Caching Implementation - Tangosol/Jboss Cacche - TBD Deployment Profile ------------------ This is how we envision our deployment profile to be. 1) Presentation Tier - Tomcat running Cocoon servlet engine. - Generate pages - Forward request to business tier 2) Business Layer - Process request using business services/actions and Data Access layer. 3) Database Layer - MYSQL with no stored procedures. Based on the above, I would like to ask the enterprise architects the following: 1) Transaction Strategy implementation - We would like to implement the transaction strategy (not Local) but either Server Transaction (using Session Facade or Command Pattern). Would you advise to use JBOss transactions API to implement this ? Has anyone had experience integrating with custom frameworks(non - Spring). Although, there is a lot of buzz about Spring and EJB3, but coonsidering that we have our custom framework (based on all top design patterns) and it performs well, we would like to integrate a Transaction API which works well, scales and is easy to implement. 2) Caching Strategy - Has anyone tried Jboss or Tangosol Cache ? If so, how would you compare the two ? We have a small home grown implementation but we have not finalized our choice...we are in a proof of concept for caching strategy. The data is going to be predominantly meta and transactional data with high read to write ratio. (80/20..approx.) 3) Messaging - Apache MQ is one of the products being considered for integration with the framework for messaging needs. Any experience with Apache MQ/Jboss Messaging ...? 4) Remoting - Has anyone tried Jboss remoting for a clustered solution ? LAN/WAN..? How does it compare to EJB based remoting solutions ? Considering that we have scalability needs, would you advise us to move to an app server deployment ? My personal views at this point(which may be incorrect) is that a regular J2SE server gives higher throughput than a J2EE server..Comments..suggestions..tips..? Regards, AS MIT
  42. This seems contradictory to Billy Newport's comments here: http://www.theserverside.com/news/thread.tss?thread_id=35626#180329"..Sharing transaction between threads isn't possible and even if it was would be a nightmare to support. It would also mean things we'd assume are single threaded and don't need synchronization would now need synchronization and slow down.Camerons interpretation is absolutely right. Different thread, different transaction...."You might need to read that thread a bit to understand the context. It seems to indicate that doing this kind of thing is difficult. Of course, I might be interpreting Billy/Cameron's comments completely incorrectly or maybe I am missing something?

    Multiple threads in the same transaction have been supported by various standards before there were threading implementations as native part of the language. (Slight historical note, I remember doing it with systems such as CThreads, Posix threads and our own thread package, back in the early 1990's). It isn't easy, for sure, but it's not impossible and it doesn't have to lead to data integrity problems if it is conformant with the standards and the implementation is well thought out.That's where checked transactions come in to play. Read the Object Transaction Service specification specification for a start. As I said before, some implementations don't support it, and that's fine. But there's nothing inherent in the model to prevent other implementations from doing so.

    Mark.