Hi,
Could one of you explain what you're talking about (versioning) in more
detail?
As I see it, the only thing we need to worry about is in transactions, and
we should prefer to act more like serializable than read committed, even if
transaction isolation is set to read committed due to use of licking
databases like Oracle.
So... within a transaction, once you've read the beans contents, you can
assume they are fixed, you don't have to look at the db again. (I am
assuming each transaction has only one copy of each entity bean instance,
so if you have a transaction spread accross several app server instances,
they communicate to get a particular bean's value rather than having
several copies and synchonizing through the db.) You can finish all your
work and send changes to the db right before commit.
Now when the next transaction starts involving the same data, unless you
know in some way that the data in the db hasn't changed, it seems to me
that you have to refetch it, or you have no idea whatsoever if it is
accurate.
So, I know of two ways that you might know if the data has changed: you are
in a Commit Option A scenario and your app is the only thing touching the
data, or you have a notification system such as Firebird/Interbase events
notifying you when data changes, so you can mark beans dependent on changed
data as invalid and needing reload.
If you are operating outside of a transaction, whatever that means, it
seems to me that you don't care if your data is accurate anyway, so we
don't need to worry either.
So I'd like to know either where I missed the boat here or where keeping
track of versions fits into this.
Thanks
David Jencks
On 2001.05.07 08:05:35 -0400 Jay Walters wrote:
> I'm not sure what this Oracle raw thing is, but I am pretty sure you
> don't
> want to be doing it. Use the indexes on primary key it'll be plenty
> fast.
>
> Just make sure tuned updates can be turned off since with Oracle it'll
> probably run faster with tuned updates off because the database won't
> have
> to be parsing all those odd statements. Of course for those people
> whoses
> rows are 32K long YMMV. By the way, does it use prepared statements
> either
> way?
>
> Where in the code does this select version thing go? Is this just done
> to
> see if you've got the right version in cache?
>
> Cheers
>
<snip>
> >
> > Finally the load today is very blind and very stupid. We just load
> > everyone. A simple implementation of the "versioning" pattern in the
> > database (where we add a field that is the version of the record)
> enables us
> > to get the right version in little time and saves us time in loading
> since
> > we can just "select version where rawID" for example :)
>
> This is a fine optional feature. I've implemented this in BMP beans and
> it shouldn't be too hard to add.
>
>
> >
> > If you are interested in leading this effort and have serious db
> background
> > please let the board know
> >
> > marc
> >
> >
> > _________________
> > Marc Fleury, Ph.D
> > [EMAIL PROTECTED]
> > _________________
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
