Markus,
you are right, but actually I do not want to have 2PC. I would expect,
that the EntityManager as well as the DataSource would use exactly the
*same* connection.
Both are accessing the same resource - so 2PC / XA are actually not
needed. The application server should not initiate a two-phase-commit
protocol in this case.
thank you for the link and help!,
adam
Markus KARG schrieb:
> Adam,
>
> I guess that the problem is that you declared the connection factory
> to use DataSource instead of XADataSource. AFAIK only XADataSource can
> participate in distributed TX, while DataSource always will use a
> local (different) exception. At least this is what I have understood
> from the JDBC spec what the main difference between DataSource and
> XADataSource is. See
> http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/xadistra.htm#i1066469.
> Can you try the same use case with "|OracleXADataSource| " instead of
> "OracleDataSource" and "XADataSource" instead of "DataSource"? Maybe
> that will help. :-)
>
> Have Fun
> Markus
>
> Adam Bien schrieb:
>> Forgot screenshot / configuration,
>>
>> adam
>>
>> Adam Bien schrieb:
>>> Hi All,
>>>
>>>
>>>
>>> I ran into following problem: Direct changes in the database (SQL
>>> updates) performed in the same Bean-method, and so transaction, are
>>> not visible for the EntityManager (subsequent find).
>>>
>>> Even invoking EntityManager#clear does not solve the problem. The
>>> problem is strange, I suspect that the DB-connection from the
>>> datasource does not participate in the TX. This would explain such
>>> behaviour.
>>>
>>>
>>>
>>> Server: Glassfishv2u2
>>>
>>> Database: OracleXE
>>>
>>>
>>>
>>> The Bean looks like:
>>>
>>>
>>>
>>>
>>>
>>> @Stateless
>>>
>>> @Remote(VehicleManager.class)
>>>
>>> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
>>>
>>> public class VehicleManagerBean implements VehicleManager {
>>>
>>>
>>>
>>> @PersistenceContext
>>>
>>> private EntityManager entityManager;
>>>
>>> @Resource(mappedName = "jdbc/db1")
>>>
>>> * private DataSource dataSource;*
>>>
>>> @EJB
>>>
>>> private DataService dataService;
>>>
>>>
>>>
>>>
>>>
>>> public Vehicle findChangeDBClearFind(int id, String newColor) {
>>>
>>> Vehicle vehicle = this.find(id);
>>>
>>> try {
>>>
>>>
>>>
>>> //changes the color of the vehicle directly in the DB
>>>
>>> * this.changeVehiclesColor(id, newColor);*
>>>
>>> * * } catch (Exception e) {
>>>
>>> throw new EJBException("Problem executing statement" + e,
>>> e);
>>>
>>> }
>>>
>>> this.entityManager.clear();
>>>
>>> return this.find(id);
>>>
>>> }
>>>
>>> private void changeVehiclesColor(int id, String color) throws
>>> Exception {
>>>
>>> Connection connection = this.dataSource.getConnection();
>>>
>>> Statement statement = connection.createStatement();
>>>
>>> String sqlStatement = "update vehicle set color=\'" + color +
>>> "\' where id=" + id;
>>>
>>> System.out.println(sqlStatement);
>>>
>>> int updatedRecords = statement.executeUpdate(sqlStatement);
>>>
>>> if (updatedRecords != 1) {
>>>
>>> throw new IllegalStateException("Vehicle with id: " + id
>>> + " cannot be updated!");
>>>
>>> }
>>>
>>> connection.close();
>>>
>>> statement.close();
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I deployed the same code to WLS 10 and it worked - the changes were
>>> visible. I suppose it is probably a configuration problem. I tried
>>> with different DataSource configurations - with no effect. I
>>> attached my current configuration as well (screenshot).
>>>
>>>
>>>
>>> Hopefully I overlooked something. If not - I will file it as a bug.
>>>
>>>
>>>
>>> Thank you in advance,
>>>
>>>
>>>
>>> regards,
>>>
>>>
>>>
>>> adam bien
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>
>
--
Consultant, Author, Java Champion
Homepage: www.adam-bien.com
Weblog: blog.adam-bien.com
eMail: abien_at_adam-bien.com
Mobile: 0049(0)170 280 3144
Books: Enterprise Architekturen (ISBN: 393504299X),
Java EE 5 Architekturen (ISBN: 3939084247),
J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts