Subject | Re: [Firebird-Java] Re: XADataSource implementation |
---|---|
Author | David Jencks |
Post date | 2002-04-25T17:20:19Z |
On 2002.04.25 12:50:42 -0400 rrokytskyy wrote:
is fraught with pitfalls, and to make it work you will end up writing most
of a ejb container. Basically you are emulating the ejbStore behavior of
entity ejbs. It is not sufficient to call this only at the end of
transactions. You also need to call it before any queries that test for
existence and after deletes and several other times. Believe me, you don't
want to try to get it to work.
tx manager for the work in cache in a transaction and in the
beforeCompletion call do all the db work.
The JDO spec basically envisions something like this for JDO in an app
server on top of a JCA driver. There appear to be some problems figuring
out when to register a new synchronization. It is possible that you will
have to wrap the XAResource for notification of the start of a transaction.
In any case, it isn't clear to me yet why such a cache would require an
XADataSource.
Constructing EJBs may be easier than you think with Middlegen (generates
entity beans directly from a database by reading the schema, allows
considerable tweaking) and xdoclet (which generates home, remote,
localhome, and local interfaces and all the deployment descriptors you need
from marked up java code). I think you would enjoy more and save a lot of
time making sure Middegen works with firebird.
Reinventing an app server is a big job. I really recommend you try JBoss.
david jencks
> > I needActually I don't remember this.
> > > XADataSource in my configuration (maybe, not sure though)
> >
> > Are you sure? Why?
>
> Not sure. :) You probably remember config I had in my mind, but I
> will put it here again:
>I REALLY REALLY REALLY recommend you try JBoss. What you are trying to do
> we are developing JCA-compliant persistence manager that in turn uses
> JDBC to store data in database. When transaction is working, we only
> cache data in memory (faster), and in XAResource.prepare(Xid) we want
> to execute corresponding SQL statements using the JDBC connection.
is fraught with pitfalls, and to make it work you will end up writing most
of a ejb container. Basically you are emulating the ejbStore behavior of
entity ejbs. It is not sufficient to call this only at the end of
transactions. You also need to call it before any queries that test for
existence and after deletes and several other times. Believe me, you don't
want to try to get it to work.
>The better way to do this is to register a synchronization object with the
> > The JCA interfaces are considerably clearer IMNSHO than the
> > XADataSource interfaces. However, it shouldn't be too hard to wrap
> > ManagedConnectionFactory with XADataSource and ManagedConnection
> > with XAConnection. I'm very curious as to why you need this,
> > however.
>
> Probably because it is not clear what happens if I try to allocate
> connection from javax.sql.DataSource in prepare(Xid) call. Will it
> belong to my transaction? Is it allowed there?
tx manager for the work in cache in a transaction and in the
beforeCompletion call do all the db work.
The JDO spec basically envisions something like this for JDO in an app
server on top of a JCA driver. There appear to be some problems figuring
out when to register a new synchronization. It is possible that you will
have to wrap the XAResource for notification of the start of a transaction.
In any case, it isn't clear to me yet why such a cache would require an
XADataSource.
Constructing EJBs may be easier than you think with Middlegen (generates
entity beans directly from a database by reading the schema, allows
considerable tweaking) and xdoclet (which generates home, remote,
localhome, and local interfaces and all the deployment descriptors you need
from marked up java code). I think you would enjoy more and save a lot of
time making sure Middegen works with firebird.
Reinventing an app server is a big job. I really recommend you try JBoss.
david jencks
>
> If you think this question is too specific, let's move to private
> email communication.
>
> Roman
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>