Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

saving unpaid itinerary

 
John Kurtman
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everybody,
Is it necessary to save unpaid itinerary in the database? Is it OK to store unpaid itinerary in a stateful session bean and save the itinerary in the database only after it is paid?
 
Deepak Pant
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes I don't think it is good idea to store intermittent conversational state in the database.

There are several options:
1. HTTP Session - web/app servers provide session replication so the state can survive the server crashes
2. Stateful Session Bean - these beans are meant for storing conversational states like unpaid itinerary but these beans do not survive server crashes.
3. Hidden Fields in forms - Not a good idea as client has to manage the code to save and re-post the hidden fields.
4. Temp Tables in the database - Not a good idea because requires lot of extra effort of storing, purging, state handling code. Also involves extra network calls.
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John,

Is it in the requirements? I know it is a good idea however, as an architect I'd question every single "feature" that is not in the requirements. In fact in real life, it is such nitty-gritty things that slip through the cracks half way during development cycle that adds complexity and cost throwing a monkeywrench into the entire project logistics. Think what you'd have done if you are architecting this project in real life and is being paid $$$ for it.

It is prudent to first focus on the stated requirements. You may want to keep such value added features in mind however, don't lose focus on delivering the well stated functionality. A system that works as required is the first thing stakeholders expect from you. As an architect you know what to expect in terms of subsequent "wouldn't it be nice if the system dd this xyz thing too" enhancements. Expect change and design smartly so that when change happens you don't have to throw away the whole thing and build it again from scratch. IMHO Saving the unpaid itinerary falls into this bucket.

For now, it is perfectly okay to use HTTPSession( plain vanilla shopping cart approach) to hold on to unsaved conversation state and write so in your documentation - that the conversation state will be lost on session time out.

HTH
 
John Kurtman
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your replies! I decided do not save unpaid itinerary in the database. I will use SFSB. I am not sure if it is the best solution but I hope it will meet the requirements.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic