----- Original Message -----
Sent: Saturday, September 16, 2006 11:48
AM
Subject: [flexcoders] Re: Data
synchronisation tip and tricks?
Hi
Paul -
Sounds like you've been doing this "database design" thing for a
while. I'm very glad to see this topic being discussed.
The topic which we're on - "Data
Synchronization" - does currently have some
discussions around them (in the form of white papers and blog posts) that I
think everybody on this thread should become familiar with to help in getting
a better and broader picture of what exactly Flex Data Management Services is
and what it was designed to solve.
This
article was written by Jeff Vroom, Software Architect working on
Flex Data Services http://tech.groups.yahoo.com/group/flexcoders/message/50090. You and the others like
you on this thread folks that are interested in more complex multi-user
database systems - are exactly the folks that we're hoping
to engage. Flex Data Management Services was written just
for you! A couple of excerpts from the
article:
"Layered on
top of those basic client/server communication facilities, the Flex Data
Management Services framework provides rich and robust data management
facilities in a client/server environment."
"Flex Data
Management Services helps solve these problems by making it easy to
synchronize data between client and server tiers without compromising the
end-user experience, the integrity of the data, or the scalability and
performance of the application. By eliminating the RPC wrappers, Data
Management Services enables you to replicate server objects to the client,
detects changes you make to these objects, and propagates these changes to the
server where a server-side data adapter handles them. One type of adapter is
the Java Adapter, which communicates these changes to your Java back end or
updates your database. Data Management Services also supports an in-memory
ActionScript adapter and an adapter that directly supports a hibernate data
model."
Another
important "something that you should know" article, written
by Ben Forta (ColdFusion Evangelist), is here at http://www.adobe.com/devnet/coldfusion/articles/fr_fds.html.
This article discusses, in particular, some reasons
why you'd want to build applications utilizing FDS vs. applications
built with RemoteObject method invocations AND compares both these
methodologies and approaches to building RIAs with multi-user consideration.
Here are a couple of excerpts the
article.
"What makes FDS really compelling is the
fact that it allows for a real bidirectional connection between the server and
the client-side Flash application. What does this mean?
Consider the following scenarios:
- Your charting
applications (powered by ColdFusion-supplied data) need to display live data
with changes to that data as they occur. You could use a timer in Flash and
poll for new data every n seconds, but what you really want is for
the server to just push new data to the client whenever there is any.
- Your
<mx:DataGrid> displays results from a database search, but that data could be
stale and you would never know it. What you want is for data changes to be
immediately reflected on the screen of any clients that happen to be looking
at that data (and not those who are not, obviously).
- Your database front end
allows users to insert, update, and delete database records. Your old web
version of the application allowed users to select a record for editing and
then submit it to be saved. But what if two users edited the same record at
once? Most likely, you just save changes as save requests occur, so the last
update always wins. That may (or may not) be appropriate in a web
application that displays a single record and refreshes pages frequently.
But in a client-server type application, where lost rows may be redisplayed
at once and pages never really refresh, the chances of overwriting on
someone else's edits are high. An ideal way is to manage data
synchronization and conflict resolution. "
"Data synchronization: This is the
ability to safely handle concurrent access to back-end data, tracking data
changes, and safely handle conflict resolution. No more
last-edit-overwrites-any-prior-edit mishaps; you can write code that ties in
to back-end data and talks to the Flash client, providing real end-to-end data
synchronization. Instead of the client talking to a CFC directly that in turn
talks to a back-end database, when using FDS and data synchronization, the
client talks to FDS, which in turn talks to a back end (ColdFusion and the
database). FDS, which sits in the middle, can arbitrate requests, monitoring
for conflicts and alerting the client of conflicts when they occur.
"
I
think that I have a unique perspective on this subject matter having
worked on both the ColdFusion team as lead quality engineer and currently on
the Flex Data Services team. I'll be checking back on this
thread for updates on the discourse!
--- In flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]>
wrote:
>
> To be honest, this is old-hat for database programmers,
yet it's rarely
> discussed in Flex/Flash circles and largely ignored in
most web discussion.
> Things tend to move up a notch in complexity once
you have to consider
> multiple users and databases.
>
>
Usually I tend to favour optimistic locking schemes on the database
since
> they don't cause problems with interactive users (send me a PM
and I'll try
> and explain it if you aren't already aware).
>
> The real issue is that potentially with multiple users (with or
without a
> database) data can be changing data underfoot, so there are
a few issues.
>
> 1) protecting data from unprotected updates
that would lose or corrupt data;
> 2) keeping the user interface updated
with changes made by other
> users/processes (which means merging the
new data with what's already
> presented to the user)
>
>
Using flags in a database to indicate what's going on in the user
interface
> is to be avoided. The particular danger with flag setting in
a database to
> indicate what's happening in the user interface is that
there will be cases
> where the user interface will not complete it's
work leaving the database
> with flags set indicating some operation is
happening when it isn't.
>
> This could be a long
discussion..
>
> I was hoping for a few war stories or snappy
techniques.
>
> Paul
> ----- Original Message -----
> From: "jbeck_sound" [EMAIL PROTECTED]
> To:
flexcoders@yahoogroups.com
> Sent: Thursday, September 14, 2006 4:32
PM
> Subject: [flexcoders] Re: Data synchronisation tip and
tricks?
>
>
> > Very good topic! I'm working on a RIA
using Flex that deals with a
> > similar situation for an online
ticketing system. Imagine two or more
> > folks selecting the same
seat and wanting to purchase a ticket for it.
> > Essentially this is
collision bound, unless it is being handled carefully.
> >
>
> I see two solutions:
> >
> > a) Use Flex Data Services
and it's real-time features of updating
> > clients with the latest
status on a specific room (in your scenario).
> > This will not
completely eliminate the possibility that both customers
> > want to
book the room at the exact same time. However, it will cut it
> >
down quite significantly. Of course, there is some additional stuff
>
> going on that we would have to take into consideration.
>
>
> > b) Use flags in the database records for each room as to
its
> > availability and return a response to a customer when the
booking is
> > committed. If someone else has beat them to it, then
an error would be
> > returned, eventually halting the rest of the
transaction based on the
> > fact that the room now is no longer
available.
> >
> > This is a very birds-eye view of what
would need to happen, at least
> > in my mind. There may be other
approaches and solutions to this
> > problem and I would be
interested to hear them!
> >
> > Jurgen
> >
>
> --- In flexcoders@yahoogroups.com, "Paul Andrews" ac297@ wrote:
>
> >
> > > Most of the traffic conversation here seems to
revolve around
> > applications
> > > that are
essentially read-only or are behaving as though they are single
> >
> user.
> > >
> > > Any tips and tricks to be found
regarding the synchronisation of
> > data in a
> > >
multi-user application involving a database.
> > >
> >
> For example (since hotel booking is a prominent example in the
RIA
> > world),
> > > lets suppose I have two customers
(Customer A and Cust B) trying to
> > book the
> > > same
hotel room on the same day. Both see it as free in the RIA, Cust A
>
> > books it and now the other must know about it too, so effectively
then
> > > that's a straight refresh of Cust B display and the
aborting of the
> > booking
> > > in progress.
>
> >
> > > Lets suppose my application allows Cust B to mark
several days of room
> > > bookings and (s)he has to hit 'book
now' to commit to the booking. While
> > > this is going on 'Cust
A' has booked one of those days, so now I
> > must merge
> >
> the updated database with the on-screen representation, so it's
no
> > longer a
> > > straight replacement of the
application display from the database, we're
> > > having to
merge.
> > >
> > > Perhaps I'd best not even mention
database locking and handling that
> > in a
> > >
RIA.
> > >
> > > Get the idea? I appreciate this isn't
entirely Flex specific.
> > >
> > > If there are tips
and tricks/best practices in this area with regard to
> > > Flex,
I'd like to know about them before I re-invent the wheel!
> >
>
> > > Paul
> > >
> >
>
>
> >
> >
> >
> > --
> >
Flexcoders Mailing List
> > FAQ:
http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> >
Search Archives:
http://www.mail-archive.com/flexcoders%40yahoogroups.com
> > Yahoo!
Groups Links
> >
> >
> >
> >
>
>
> >
> >
> >
> >
> >
>
>
>
