Hi,
I don't remember much about this, but I seem to recall that perhaps
IBConsole uses CommitRetaining rather than Commit... this would mean you
would NEVER see updates from other people until you restarted IBConsole.
In my opinion IBConsole is most appropriate for those developing single
user apps in Delphi.
I strongly suggest you try Interclient 2.0 and ant's SQLExec task, or ask
me for my SQL-XML.
In particular... what do your ejb's see? Are they consistent with what you
thought you put in?
On 2001.03.28 02:44:43 -0500 René Rolander Nygaard wrote:
> Hey - I'm from the same company as Torsten Terp, så the answars go for
> both
> of us :-)
>
> > Hi,
> >
> > How do you determine if the data is in the database? My recent
> experience
> > is that isql is very flakey, I couldn't see results in it that my jboss
> > client could see. I have an ant-based sql-xml task however that
> > consistently sees just what the jboss client sees. You could try ant's
> > sqlexec task or I would be happy to send you mine.
>
> We are using the Interbase 1.6.
> For all our database updates we have switches from the visual IBconsole,
> to
> ISql. The main reason is in IBConsole the program was unable to "release"
> a
> table. F.ex. if we make a temp. table, copy all data to this table, and
> then
> tries to drop the table, IBconsole tells us that the table is in use!
> Whenever we do use IBconsole, we always disconnect after updates, and
> data-saves. The data was visible to JBoss instantly.
> The ISql have no problems with the above problems.
>
> > Remember that Firebird/Interbase by default has snapshot transaction
> > isolation - not read committed. In particular this means that if
> > you start
> > a transaction in isql-- I'm not sure if this happens when you log in or
> > execute a select statement-- you will see noones updates until you
> commit
> > (after your read only query. Takes a little getting used to-- but
> allows
> > for accurate reports).
> >
> > On the other hand, the odd results I was seeing seemed to go beyond
> this
> > transaction isolation behavior.
> >
> > I'm curious if this provides a consitent view of the data for you.
>
> When is JBoss excepted to save data to the database ?
> I though JBoss was expected to delay the physical UPDATE / INSERT
> statements
> due to 1: performance (only one update statement, instead of a lot of
> single
> updates) and 2: missing values (in a INSERT JBoss need all NOT-NULL
> values
> before it can make the INSERT statement.
>
> - René
My impression ( I can't cite the section and verse of the spec) is that
after a create the bean/container MUST perform an insert and an immediate
read ( presumably to pick up values set by defaults/triggers???) ( I
haven't looked to see what jboss actually does, either)
My experience with unoptimised jaws is that a update is performed after
every set method call. I think if jaws is optimized, at most one update is
performed immediately before commit. Looking for the data from another
process, it shouldn't make any difference when the updates are performed,
or how often: transaction isolation will make them invisible to all other
transactions until commit.
David Jencks
<snip>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
