How Spread­shirt used Atomikos to mi­grate away from the JEE app serv­er

Spread­shirt is a glob­al e-com­merce plat­form for every­one to cre­ate, sell and buy ideas on cloth­ing and ac­ces­sories across many points of sale.

"At the time we were us­ing Java EE 5 (EJB 3.0) and Glass­fish Ap­pli­ca­tion Serv­er. The (clus­tered) ap­pli­ca­tion be­came pret­ty mono­lith­ic, con­fig­u­ra­tion was tough (edit­ing huge xml files was best prac­tice) and the tech stack was very rigid. One of the prob­lems we had was that all in­stances of the ap­pli­ca­tion were con­sum­ing mes­sages and serv­ing HTTP re­quests, per­for­mance suf­fered. Also, re­leas­es on Glass­fish took very long, sta­bil­i­ty suf­fered. Pro­duc­tion, QA, DEV en­vi­ron­ments were dif­fer­ing in many ways mak­ing it im­pos­si­ble to think about con­ti­nous in­te­gra­tion / de­liv­ery.

We first had some good ex­pe­ri­ences us­ing Atomikos for unit test­ing (most­ly per­sis­tence lay­er and mes­sag­ing) be­cause it was way faster.

We could mi­grate from EJB to Spring with keep­ing most of the ap­pli­ca­tion as it was: mul­ti­ple per­sis­tence units (JPA/Hiber­nate), caching (Eh­cache), mes­sag­ing (Ac­tiveMQ), XA trans­ac­tions (now Atomikos). Atomikos sup­port­ed us a lot by pro­vid­ing ad­vice and cus­tom ver­sions of Atomikos that re­flect­ed our spe­cif­ic en­vi­ron­ment. We fi­nal­ly switched off Glass­fish and moved to much more light­weight em­bed­ded Servlet con­tain­ers (Jet­ty). Over time we broke the mono­lith­ic ap­pli­ca­tion down into small­er pieces that were han­dled by dif­fer­ent teams.

We rec­om­mend Atomikos if you are mi­grat­ing ex­ist­ing mono­lith­ic JEE ap­pli­ca­tions to Spring, and for Spring-based ap­pli­ca­tions com­plex trans­ac­tion han­dling un­der high load."

Who else uses Atomikos? Check out some of our cus­tomers!