MySQL Bugs: #12866: No accessible transaction id within triggers

Bug #12866	No accessible transaction id within triggers
Submitted:	30 Aug 2005 3:11	Modified:	14 Oct 2009 9:09
Reporter:	Frank McGeough	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: General	Severity:	S4 (Feature request)
Version:	5.0.11	OS:	Windows (Windows 2003 server)
Assigned to:		CPU Architecture:	Any

Description:
There is nothing in the trigger documentation or in the standard procedures that specifies how to uniquely identify a transaction. What is needed is a transaction id. This is available on Microsoft SQL Server, Oracle, and Sybase SQL Anywhere (its not available on db2 as far as I know). One use case is if I wish to log information about operations within a transaction to a reporting table.  I can not do so currently because I have no identifier with which to group the operations within a transaction. 

How to repeat:
Missing feature.

Suggested fix:
A guid generated internally by the engine at the start of a transaction and used to identify a transaction would be ideal. The trigger should be able to call TRANSACTION_ID() just like we can now call CONNECTION_ID(). It should probably return a string to give the most flexibility to the implementation. It just needs to be unique which is why a guid meets the criteria.

I need this as well.

+1, if it means anything.

Thank you for the feature request.

The same here. Feature absolutely requested. Overall, if one wants to support Oracle and MySQL. The complete system is based on Oracle and we would like to have a full support of MySQL. However, without this feature, the MySQL support for our applications is a no-go.

Should this not be doable using the XID used in XA support? (i.e. something from the return value of thd_get_xid()) The base64-encoded value of data could work, although this could be 100+ chars long.